-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow Iceberg MV with partitioning transforms on timestamptz #16637
Conversation
f9153a0
to
4664627
Compare
`storageSchemaName` is defined on class level, so the storage schema should be created in `@BeforeClass`, not within a test.
4664627
to
6ca801c
Compare
plugin/trino-iceberg/src/main/java/io/trino/plugin/iceberg/PartitionTransforms.java
Show resolved
Hide resolved
Build green (https://github.com/trinodb/trino/actions/runs/4481491874/jobs/7878270959?pr=16637). |
a289513
to
0dbd356
Compare
plugin/trino-iceberg/src/test/java/io/trino/plugin/iceberg/BaseIcebergMaterializedViewTest.java
Outdated
Show resolved
Hide resolved
plugin/trino-iceberg/src/main/java/io/trino/plugin/iceberg/catalog/AbstractTrinoCatalog.java
Show resolved
Hide resolved
Allow creation of Iceberg Materialized Views partitioned with a temporal partitioning function on a `timestamp with time zone` column. In MVs, the `timestamp with time zone` columns are generally stored as text to preserve time zone information. However, this prevents use of temporal partitioning functions on these columns. The commit keeps `timestamp with time zone` columns with partitioning applied on them as `timestamp with time zone` in the storage table. An obvious downside to this approach is that the time zone information is erased and it is not known whether this aligns with user intention or not. A better solution would be to introduce a point-in-time type (#2273) to discern between the cases where time zone information is important (like Java's `ZonedDateTime`) from cases where only point-in-time matters (like Java's `Instant`).
0dbd356
to
79c7c29
Compare
They were probably copied over from the preceding backtick test case.
plugin/trino-iceberg/src/main/java/io/trino/plugin/iceberg/catalog/AbstractTrinoCatalog.java
Show resolved
Hide resolved
return new Object[][] { | ||
{"year", "date", "DATE '2005-09-09'"}, | ||
{"year", "timestamp(6)", "TIMESTAMP '2005-09-10 13:31:00.123456'"}, | ||
{"year", "timestamp(6) with time zone", "TIMESTAMP '2005-09-10 13:00:00.123456 Europe/Warsaw'"}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the timestamp with time zone tests, can you add a second value that has the same time but in a different zone and show that works properly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, a test with precision > 6?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, a test with precision > 6?
this is not supported
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you add a second value that has the same time but in a different zone and show that works properly?
it wouldn't be any different. Europe/Warsaw is not test's JVM zone so it's not special
Allow creation of Iceberg Materialized Views partitioned with a
temporal partitioning function on a
timestamp with time zone
column.In MVs, the
timestamp with time zone
columns are generally stored astext to preserve time zone information. However, this prevents use of
temporal partitioning functions on these columns. The commit keeps
timestamp with time zone
columns with partitioning applied on them astimestamp with time zone
in the storage table.An obvious downside to this approach is that the time zone information
is erased and it is not known whether this aligns with user intention or
not. A better solution would be to introduce a point-in-time type
(#2273) to discern between the
cases where time zone information is important (like Java's
ZonedDateTime
) from cases where only point-in-time matters (likeJava's
Instant
).