OK, I think I have completed the initial changes for the new interval type
in https://github.com/apache/arrow/pull/10177
The code changes still need to be reviewed, but I don't think that should
stop a vote. I'll start a vote on Monday unless there are more comments on
the format changes.
Thanks
As an update, I've gotten basic integration testing working in Java and C++
along with the format proposal updates [1].
I have a little bit more work to do on the initial implementations (make CI
happy, add unit tests in Java) but I think this is getting close to the
point that we can vote on it.
Ah, that makes sense to wait then.
On Thu, May 6, 2021 at 10:55 AM Micah Kornfield wrote:
>
> I'll address the feedback. I think in the past we've waited for
> implementations in java and c++ with integration tests before formally
> voting. If there is no more feedback I can start looking at
I'll address the feedback. I think in the past we've waited for
implementations in java and c++ with integration tests before formally
voting. If there is no more feedback I can start looking at
implementations (happy to have help)
On Thursday, May 6, 2021, Wes McKinney wrote:
> The PR looks g
I agree with you that having fixed precision (e.g. postgres / zetasql) is
reasonable. Variable precision fields (ala SQL Server/Oracle) seem less
valuable to me.
I think support for nanosecond precision for intervals is important as
there are nanosecond precision timestamps
I don't think the post
To follow-up on this conversation I did some analysis on interval types:
https://docs.google.com/document/d/1i1E_fdQ_xODZcAhsV11Pfq27O50k679OYHXFJpm9NS0/edit
Please feel free to add more details/systems I missed.
Given the disparate requirements of different systems I think the following
might
