+1 (binding)

On Thu, Jun 25, 2026 at 1:58 PM Matt Topol <[email protected]> wrote:

> +1 (binding)
>
> On Thu, Jun 25, 2026, 2:52 PM Amogh Jahagirdar <[email protected]> wrote:
>
>> +1 (binding)
>>
>> On Thu, Jun 25, 2026 at 11:53 AM Prashant Singh <[email protected]>
>> wrote:
>>
>>> +1 (binding)
>>>
>>> Thanks,
>>> Prashant Singh
>>>
>>> On Thu, Jun 25, 2026 at 10:49 AM Daniel Weeks <[email protected]> wrote:
>>>
>>>> +1 (binding)
>>>>
>>>> On Thu, Jun 25, 2026 at 10:13 AM Sung Yun <[email protected]> wrote:
>>>>
>>>>> +1 (binding)
>>>>>
>>>>> On 2026/06/25 16:48:20 Ryan Blue wrote:
>>>>> > +1 (binding)
>>>>> >
>>>>> > On Thu, Jun 25, 2026 at 9:24 AM Yufei Gu <[email protected]>
>>>>> wrote:
>>>>> >
>>>>> > > +1(binding)
>>>>> > >
>>>>> > > Yufei
>>>>> > >
>>>>> > >
>>>>> > > On Thu, Jun 25, 2026 at 9:13 AM Russell Spitzer <
>>>>> [email protected]>
>>>>> > > wrote:
>>>>> > >
>>>>> > >> +1 (binding)
>>>>> > >> On Thu, Jun 25, 2026 at 10:45 AM Alexandre Dutra <
>>>>> [email protected]>
>>>>> > >> wrote:
>>>>> > >>
>>>>> > >>> +1 (non-binding)
>>>>> > >>>
>>>>> > >>> On Thu, Jun 25, 2026 at 5:03 PM Gang Wu <[email protected]>
>>>>> wrote:
>>>>> > >>> >
>>>>> > >>> > +1 (non-binding)
>>>>> > >>> >
>>>>> > >>> > Posted some minor comments but overall good to have them!
>>>>> > >>> >
>>>>> > >>> > On Thu, Jun 25, 2026 at 10:27 PM Andrei Tserakhau via dev
>>>>> > >>> > <[email protected]> wrote:
>>>>> > >>> > >
>>>>> > >>> > > +1 (non-binding)
>>>>> > >>> > >
>>>>> > >>> > > чт, 25 июн. 2026 г., 16:20 Manu Zhang <
>>>>> [email protected]>:
>>>>> > >>> > >>
>>>>> > >>> > >> +1 (non-binding). I'm really excited about the use cases it
>>>>> can
>>>>> > >>> unblock.
>>>>> > >>> > >>
>>>>> > >>> > >> Thanks,
>>>>> > >>> > >> Manu
>>>>> > >>> > >>
>>>>> > >>> > >> On Thu, Jun 25, 2026 at 1:27 PM Szehon Ho <
>>>>> [email protected]>
>>>>> > >>> wrote:
>>>>> > >>> > >>>
>>>>> > >>> > >>> +1 (binding)
>>>>> > >>> > >>>
>>>>> > >>> > >>> Went over it, it seems a nice elegant definition.
>>>>> > >>> > >>> Thanks
>>>>> > >>> > >>> Szehon
>>>>> > >>> > >>>
>>>>> > >>> > >>> On Wed, Jun 24, 2026 at 9:00 PM Anoop Johnson <
>>>>> [email protected]>
>>>>> > >>> wrote:
>>>>> > >>> > >>>>
>>>>> > >>> > >>>> +1 (non-binding)
>>>>> > >>> > >>>>
>>>>> > >>> > >>>> On Wed, Jun 24, 2026 at 7:26 PM Steven Wu <
>>>>> [email protected]>
>>>>> > >>> wrote:
>>>>> > >>> > >>>>>
>>>>> > >>> > >>>>> +1 (binding)
>>>>> > >>> > >>>>>
>>>>> > >>> > >>>>> On Wed, Jun 24, 2026 at 3:52 PM Ryan Blue <
>>>>> [email protected]>
>>>>> > >>> wrote:
>>>>> > >>> > >>>>>>
>>>>> > >>> > >>>>>> Hi everyone,
>>>>> > >>> > >>>>>>
>>>>> > >>> > >>>>>> I'd like to start a vote to adopt the new expressions
>>>>> spec.
>>>>> > >>> This spec defines the minimal structure and behavior of
>>>>> expressions that
>>>>> > >>> Iceberg formats need to store and exchange. This is intended to
>>>>> clean up
>>>>> > >>> expressions used in the REST catalog spec (exchanging query
>>>>> filters) and to
>>>>> > >>> enable new use cases that require expressions to be stored in
>>>>> metadata,
>>>>> > >>> including expression defaults (`current_timestamp()`) and `CHECK`
>>>>> > >>> constraints (`col < 360.0`).
>>>>> > >>> > >>>>>>
>>>>> > >>> > >>>>>> This spec is PR #16652. Thank you to everyone that has
>>>>> > >>> discussed this in community syncs or reviewed the design doc and
>>>>> PR!
>>>>> > >>> > >>>>>>
>>>>> > >>> > >>>>>> Please vote in the next 72 hours:
>>>>> > >>> > >>>>>>
>>>>> > >>> > >>>>>> [ ] +1: Adopt the expressions spec
>>>>> > >>> > >>>>>> [ ] +0: . . .
>>>>> > >>> > >>>>>> [ ] -1: Do not add the spec because . . .
>>>>> > >>> > >>>>>>
>>>>> > >>> > >>>>>> Thanks,
>>>>> > >>> > >>>>>>
>>>>> > >>> > >>>>>> Ryan
>>>>> > >>>
>>>>> > >>
>>>>> >
>>>>>
>>>>

Reply via email to