Re: [VOTE] Small spec change for default values

[Daniel Weeks]

+1 (binding)

On Wed, Apr 23, 2025, 3:12 PM Anton Okolnychyi 
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  пише:
>
>> +1 (binding)
>>
>> On Wed, Apr 23, 2025 at 8:39 AM Fokko Driesprong 
>> wrote:
>>
>>> +1 (binding)
>>>
>>> Kind regards,
>>> Fokko
>>>
>>> Op wo 23 apr 2025 om 03:08 schreef Gang Wu :
>>>
 +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é 
>> wrote:
>>
>>> +1 (non binding)
>>>
>>> Regards
>>> JB
>>>
>>> On Mon, Apr 21, 2025 at 11:20 PM Ryan Blue  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>> 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
>>>
>>

Re: [VOTE] Small spec change for default values

[Anton Okolnychyi]

+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  пише:

> +1 (binding)
>
> On Wed, Apr 23, 2025 at 8:39 AM Fokko Driesprong  wrote:
>
>> +1 (binding)
>>
>> Kind regards,
>> Fokko
>>
>> Op wo 23 apr 2025 om 03:08 schreef Gang Wu :
>>
>>> +1 (non-binding)
>>>
>>> On Wed, Apr 23, 2025 at 4:42 AM Prashant Singh 
>>> 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é 
> wrote:
>
>> +1 (non binding)
>>
>> Regards
>> JB
>>
>> On Mon, Apr 21, 2025 at 11:20 PM Ryan Blue  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> 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
>>
>

Re: [VOTE] Small spec change for default values

[Ryan Blue]

+1 (binding)

On Wed, Apr 23, 2025 at 8:39 AM Fokko Driesprong  wrote:

> +1 (binding)
>
> Kind regards,
> Fokko
>
> Op wo 23 apr 2025 om 03:08 schreef Gang Wu :
>
>> +1 (non-binding)
>>
>> On Wed, Apr 23, 2025 at 4:42 AM Prashant Singh 
>> 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é 
 wrote:

> +1 (non binding)
>
> Regards
> JB
>
> On Mon, Apr 21, 2025 at 11:20 PM Ryan Blue  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 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
>

Re: [VOTE] Small spec change for default values

[Fokko Driesprong]

+1 (binding)

Kind regards,
Fokko

Op wo 23 apr 2025 om 03:08 schreef Gang Wu :

> +1 (non-binding)
>
> On Wed, Apr 23, 2025 at 4:42 AM Prashant Singh 
> 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é 
>>> wrote:
>>>
 +1 (non binding)

 Regards
 JB

 On Mon, Apr 21, 2025 at 11:20 PM Ryan Blue  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>>> 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

>>>

Re: [VOTE] Small spec change for default values

[Gang Wu]

+1 (non-binding)

On Wed, Apr 23, 2025 at 4:42 AM Prashant Singh 
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é 
>> wrote:
>>
>>> +1 (non binding)
>>>
>>> Regards
>>> JB
>>>
>>> On Mon, Apr 21, 2025 at 11:20 PM Ryan Blue  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>> 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
>>>
>>

Re: [VOTE] Small spec change for default values

[Steve Zhang]

+1 (non binding)

Thanks,
Steve Zhang



> On Apr 22, 2025, at 1:41 PM, Prashant Singh  wrote:
> 
> +1 (non-binding)
> 
> Best,
> Prashant Singh
> 
> On Tue, Apr 22, 2025 at 2:55 AM Eduard Tudenhöfner  > wrote:
>> +1
>> 
>> On Tue, Apr 22, 2025 at 7:31 AM Jean-Baptiste Onofré > > wrote:
>>> +1 (non binding)
>>> 
>>> Regards
>>> JB
>>> 
>>> On Mon, Apr 21, 2025 at 11:20 PM Ryan Blue >> > 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>> > 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

Re: [VOTE] Small spec change for default values

[Prashant Singh]

+1 (non-binding)

Best,
Prashant Singh

On Tue, Apr 22, 2025 at 2:55 AM Eduard Tudenhöfner 
wrote:

> +1
>
> On Tue, Apr 22, 2025 at 7:31 AM Jean-Baptiste Onofré 
> wrote:
>
>> +1 (non binding)
>>
>> Regards
>> JB
>>
>> On Mon, Apr 21, 2025 at 11:20 PM Ryan Blue  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> 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
>>
>

Re: [VOTE] Small spec change for default values

[Eduard Tudenhöfner]

+1

On Tue, Apr 22, 2025 at 7:31 AM Jean-Baptiste Onofré 
wrote:

> +1 (non binding)
>
> Regards
> JB
>
> On Mon, Apr 21, 2025 at 11:20 PM Ryan Blue  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 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
>

Re: [VOTE] Small spec change for default values

[Jean-Baptiste Onofré]

+1 (non binding)

Regards
JB

On Mon, Apr 21, 2025 at 11:20 PM Ryan Blue  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 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

Re: [VOTE] Small spec change for default values

[Walaa Eldin Moustafa]

+1 to the direction (non-binding).

Left some clarification comments on the PR.

Thanks,
Walaa.

On Mon, Apr 21, 2025 at 10:57 PM Manu Zhang  wrote:

> +1 (non-binding) except for some ambiguity between struct field and fields
> within struct (Russell already made a nice suggestion).
>
> Thanks,
> Manu
>
> On Tue, Apr 22, 2025 at 7:10 AM Amogh Jahagirdar <2am...@gmail.com> wrote:
>
>> +1 (binding)
>>
>> On Mon, Apr 21, 2025 at 3:38 PM Russell Spitzer <
>> russell.spit...@gmail.com> wrote:
>>
>>> +1 (Binding)
>>>
>>> On Mon, Apr 21, 2025 at 4:21 PM Ryan Blue  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>>> 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

>>>

Re: [VOTE] Small spec change for default values

[Manu Zhang]

+1 (non-binding) except for some ambiguity between struct field and fields
within struct (Russell already made a nice suggestion).

Thanks,
Manu

On Tue, Apr 22, 2025 at 7:10 AM Amogh Jahagirdar <2am...@gmail.com> wrote:

> +1 (binding)
>
> On Mon, Apr 21, 2025 at 3:38 PM Russell Spitzer 
> wrote:
>
>> +1 (Binding)
>>
>> On Mon, Apr 21, 2025 at 4:21 PM Ryan Blue  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>> 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
>>>
>>

Re: [VOTE] Small spec change for default values

[Amogh Jahagirdar]

+1 (binding)

On Mon, Apr 21, 2025 at 3:38 PM Russell Spitzer 
wrote:

> +1 (Binding)
>
> On Mon, Apr 21, 2025 at 4:21 PM Ryan Blue  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> 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
>>
>

Re: [VOTE] Small spec change for default values

[Russell Spitzer]

+1 (Binding)

On Mon, Apr 21, 2025 at 4:21 PM Ryan Blue  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 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
>