emkornfield commented on a change in pull request #10177:
URL: https://github.com/apache/arrow/pull/10177#discussion_r622313786
##########
File path: format/Schema.fbs
##########
@@ -246,15 +246,21 @@ table Timestamp {
timezone: string;
}
-enum IntervalUnit: short { YEAR_MONTH, DAY_TIME}
+enum IntervalUnit: short { YEAR_MONTH, DAY_TIME, MONTH_DAY_NANO}
// A "calendar" interval which models types that don't necessarily
// have a precise duration without the context of a base timestamp (e.g.
// days can differ in length during day light savings time transitions).
+// All integers in the types below are stored in the endianness indicated
+// by the schema.
// YEAR_MONTH - Indicates the number of elapsed whole months, stored as
// 4-byte integers.
// DAY_TIME - Indicates the number of elapsed days and milliseconds,
// stored as 2 contiguous 32-bit integers (8-bytes in total). Support
// of this IntervalUnit is not required for full arrow compatibility.
+// MONTH_DAY_NANOS - A triple of # of elapsted months, days, and nanoseconds.
+// The values are stored contiguously in 16 byte blocks. Months and
+// days are encoded as 32 bit integers and nanoseconds is encoded as a
Review comment:
So for YEAR_MONTH it is signed I believe.
The case of DAY_TIME is a little bit more ambiguous, I'm not aware of any
validation we do today and here is what postgres docs say about the SQL
standard.
```
According to the SQL standard all fields of an interval value must have the
same sign, so a leading negative sign applies to all fields; for example the
negative sign in the interval literal '-1 2:03:04' applies to both the days and
hour/minute/second parts. PostgreSQL allows the fields to have different signs,
and traditionally treats each field in the textual representation as
independently signed, so that the hour/minute/second part is considered
positive in this example. If IntervalStyle is set to sql_standard then a
leading sign is considered to apply to all fields (but only if no additional
signs appear). Otherwise the traditional PostgreSQL interpretation is used. To
avoid ambiguity, it's recommended to attach an explicit sign to each field if
any field is negative.
```
For the new type, based on the docs, I'd propose all values are signed?
Sound reasonable.
--
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.
For queries about this service, please contact Infrastructure at:
[email protected]
