hi Jacques, > - We have outstanding questions around union type. I think the main on is the > javascript type. Given the inability to support the desired behavior for > decimal type, I suggest we remove this capability before 1.0.
I may have missed something, but I'm not remembering either the points re: JavaScript or decimals. My understanding is that we have been discussing how to handle a union-of-complex-types -- the Union implementation in Java does not support this. Could you clarify or refer to prior mailing list threads? > - Interval Day to Seconds: 8 bytes representing number of > milliseconds. > - Interval Year to Months: 4 bytes representing number of months. Yes, I'm supportive of this. The one addition is that we need to add a "unit" field to the metadata to support finer granularity than milliseconds -- the idea is that we should support the same units as TImestamp so that a difference of timestamps produces an interval (aka timedelta). We have this data arising already in Python, for example, but we cannot represent it in Arrow at the moment, so this has been a rough edge for users. - Wes On Mon, Mar 19, 2018 at 9:48 PM, Jacques Nadeau <jacq...@apache.org> wrote: > A couple of outstanding questions around format that I think we need to > cover before 1.0 > > - We have outstanding questions around union type. I think the main one > is the javascript type. Given the inability to support the desired behavior > for decimal type, I suggest we remove this capability before 1.0. > - For interval, I'd like to propose moving to a single value > representation instead of a composite. I think that it is unlikely that > anyone needs a composite representation. If they do, they can compose their > own with the other primitives available. I believe this would look like: > - Interval Day to Seconds: 8 bytes representing number of > milliseconds. > - Interval Year to Months: 4 bytes representing number of months. > > Thoughts?
