With 7 +1 votes and 1 -0, this passes. I'll work with Micah to clarify some of the sections that he pointed out, but I don't think that we need to block moving forward on the overall set of things that are proposed. Thanks, everyone!
On Tue, Oct 1, 2024 at 1:49 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > +1 (non binding) > > Regards > JB > > On Fri, Sep 27, 2024 at 11:36 PM rdb...@gmail.com <rdb...@gmail.com> > wrote: > > > > Hi everyone, > > > > I'd like to vote on PR #10955 that has been open for a while with the > changes to add new type promotion cases. After discussion, the PR has been > scoped down to keep complexity low. It now adds: > > > > * An `unknown` type for cases when only `null` values have been observed > > * Type promotion from `unknown` to any other type > > * Type promotion from `date` to `timestamp` or `timestamp_ns` > > * Clarification that promotion is not allowed if it breaks transform > results > > > > The set of changes is quite a bit smaller than originally proposed > because of the issue already discussed about lower and upper bounds values, > and it no longer includes variant. I think that we can add more type > promotion cases after we improve bounds metadata. This adds what we can now > to keep v3 moving forward. > > > > Please vote in the next 72 hours: > > > > [ ] +1, commit the proposed spec changes > > [ ] -0 > > [ ] -1, do not make these changes because . . . > > > > Thanks, > > > > Ryan >
