lidavidm commented on code in PR #496:
URL: https://github.com/apache/parquet-format/pull/496#discussion_r2160030278
##########
src/main/thrift/parquet.thrift:
##########
@@ -461,6 +461,29 @@ struct GeographyType {
2: optional EdgeInterpolationAlgorithm algorithm;
}
+/**
+ * Year-Month Interval logical type annotation
+ *
+ * The data is stored as an 4 byte signed integer which represents the number
+ * of months associated with the time interval. The value can be negative to
+ * indicate a backward duration.
+ *
+ * Allowed for physical type: INT32
+ */
+struct IntervalYearMonthType {
+}
+
+/**
+ * Month-Day Interval logical type annotation
+ *
+ * The data is stored as a 16-byte signed value, which represents the number
Review Comment:
IMO, it's less "We need a month-day-nano type" and more "can we unify
DayTimeInterval and MonthDayNano"? It sounds like ~maybe, if we're willing to
accept a somewhat more complicated representation. Or maybe the complexity
should be pushed to the Arrow side (with the encoding Micah suggests). But
that's why I suggested making sure we open a dialogue with the Arrow community
too (since the encoding is somewhat fraught: again, there's a mismatch between
ANSI SQL having what is really a duration or absolute time difference, and
MonthDayNano being an "actual" interval, so I'm not quite convinced we want to
translate in this way).
Given (for instance) PyIceberg, iceberg-rust, and iceberg-cpp use Arrow (to
different extents), I think having a mapping with clearly defined semantics
isn't an abstract concern for Iceberg implementations and the question
shouldn't just be dropped.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
