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?

Reply via email to