gh-yzou commented on code in PR #496:
URL: https://github.com/apache/parquet-format/pull/496#discussion_r2159814278
##########
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:
Hi @zeroshade and @emkornfield Thanks a lot for the feedbacks! Sorry, it
took me sometime to catch up here. Thanks a lot to bring up the point about
MonthDayNano.
I felt the communities has been put on a lot of effort to push standard
across SQL engines (I might be wrong). From that point of view, i do feel is is
important to come with a standard can ease the sharing cross different SQL
engines and stay close with the SQL standard.
As for MonthDayNano, although Spark today does have a CalendarInterval type,
it seems that the recommended user facing type is still YearMonthInterval and
MonthDayInterval. Furthermore, i think having YearMonthInterval and
DayTimeInterval doesn't really block us to also support the MonthDayNano in the
near future if it is necessary.
So I think it might make more sense to support YearMonthInterval and
DayTimeInterval, which probably satisfies most of the cross engine sharing use
cases, and then if there is high demand for the other type, we can also
considering adding it to make the type system richer. What do you think?
--
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]
