+1 (binding) On Wed, Apr 23, 2025, 3:12 PM Anton Okolnychyi <aokolnyc...@gmail.com> wrote:
> +1 (binding) > > The proposed V3 behavior would already be a lot more flexible than what > most engines support in the industry today. It is also not covered by the > SQL standard, so there is no need to overcomplicate the spec without actual > use cases. > > - Anton > > ср, 23 квіт. 2025 р. о 10:27 Ryan Blue <rdb...@gmail.com> пише: > >> +1 (binding) >> >> On Wed, Apr 23, 2025 at 8:39 AM Fokko Driesprong <fo...@apache.org> >> wrote: >> >>> +1 (binding) >>> >>> Kind regards, >>> Fokko >>> >>> Op wo 23 apr 2025 om 03:08 schreef Gang Wu <ust...@gmail.com>: >>> >>>> +1 (non-binding) >>>> >>>> On Wed, Apr 23, 2025 at 4:42 AM Prashant Singh < >>>> prashant010...@gmail.com> wrote: >>>> >>>>> +1 (non-binding) >>>>> >>>>> Best, >>>>> Prashant Singh >>>>> >>>>> On Tue, Apr 22, 2025 at 2:55 AM Eduard Tudenhöfner < >>>>> etudenhoef...@apache.org> wrote: >>>>> >>>>>> +1 >>>>>> >>>>>> On Tue, Apr 22, 2025 at 7:31 AM Jean-Baptiste Onofré <j...@nanthrax.net> >>>>>> wrote: >>>>>> >>>>>>> +1 (non binding) >>>>>>> >>>>>>> Regards >>>>>>> JB >>>>>>> >>>>>>> On Mon, Apr 21, 2025 at 11:20 PM Ryan Blue <rdb...@gmail.com> wrote: >>>>>>> > >>>>>>> > Hi everyone, >>>>>>> > >>>>>>> > I’d like to vote on the spec changes in PR 12841. This is a small >>>>>>> change that makes handling default values for structs much easier. >>>>>>> Initially, we allowed both a struct and its fields to have default >>>>>>> values, >>>>>>> but the values could conflict. For instance, ADD COLUMN point struct<x >>>>>>> int >>>>>>> default 0, y int default 0> default struct(-1, -1). >>>>>>> > >>>>>>> > The fix is to always track default values at the field level and >>>>>>> allow only null or null-null for the struct level defaults. That makes >>>>>>> the >>>>>>> feature more predictable because the struct’s default never needs to be >>>>>>> modified or have field-level changes applied (i.e. removing field y or >>>>>>> adding field z). >>>>>>> > >>>>>>> > In addition, I want to mention that this is not a one-way >>>>>>> decision. We can always allow the struct-level default to differ later, >>>>>>> if >>>>>>> we have use cases in which a missing struct needs to have a different >>>>>>> default than missing fields. >>>>>>> > >>>>>>> > Please vote in the next 72 hours: >>>>>>> > >>>>>>> > [ ] +1 Add these changes to the spec >>>>>>> > [ ] +0 >>>>>>> > [ ] -1 I have questions and/or concerns >>>>>>> > >>>>>>> > Thanks, >>>>>>> > >>>>>>> > Ryan >>>>>>> >>>>>>
