+1 (nb)
On Tue, Mar 10, 2026 at 10:48 AM Eduard Tudenhöfner <[email protected]> wrote: > > +1 > > On Tue, Mar 10, 2026 at 9:28 AM Péter Váry <[email protected]> > wrote: >> >> +1 >> >> Steven Wu <[email protected]> ezt írta (időpont: 2026. márc. 10., K, >> 5:04): >>> >>> +1 (binding) for the spec >>> >>> On Mon, Mar 9, 2026 at 8:04 PM roryqi <[email protected]> wrote: >>>> >>>> +1 (non-binding) >>>> >>>> huaxin gao <[email protected]> 于2026年3月10日周二 10:07写道： >>>> > >>>> > +1 (non-binding) >>>> > >>>> > On Mon, Mar 9, 2026 at 6:44 PM Yufei Gu <[email protected]> wrote: >>>> >> >>>> >> +1 >>>> >> Yufei >>>> >> >>>> >> >>>> >> On Mon, Mar 9, 2026 at 9:37 AM Prashant Singh >>>> >> <[email protected]> wrote: >>>> >>> >>>> >>> Thanks for the feedback Ryan, splitted the PR into 2 : >>>> >>> SPEC PR: https://github.com/apache/iceberg/pull/14867 >>>> >>> Client Side Impl : https://github.com/apache/iceberg/pull/15572 >>>> >>> >>>> >>> Best, >>>> >>> Prashant Singh >>>> >>> >>>> >>> >>>> >>> >>>> >>> On Mon, Mar 9, 2026 at 9:12 AM Ryan Blue <[email protected]> wrote: >>>> >>>> >>>> >>>> +1 for the spec changes, but I don't think that we should mix >>>> >>>> implementation and spec changes in the same PR. Could you remove the >>>> >>>> implementation changes? >>>> >>>> >>>> >>>> On Mon, Mar 9, 2026 at 9:03 AM Prashant Singh >>>> >>>> <[email protected]> wrote: >>>> >>>>> >>>> >>>>> Hey All, >>>> >>>>> >>>> >>>>> I propose adding scan-planning-mode to loadTable API, which is an >>>> >>>>> optional value in the loadTable config section, which when present >>>> >>>>> clients MUST use it to decide which mode of scan planning they wanna >>>> >>>>> do, server side (using IRC scan planning API) or client side (client >>>> >>>>> reading the manifest and then figuring out FileScan Tasks). >>>> >>>>> >>>> >>>>> For details please check : >>>> >>>>> - PR : https://github.com/apache/iceberg/pull/14867 >>>> >>>>> >>>> >>>>> Some summary on background discussion : >>>> >>>>> We debated a lot offline on what does MUST means to the client, as >>>> >>>>> if does the client has a liberty to fail fast if they have >>>> >>>>> configured something in their client side config which is orthogonal >>>> >>>>> to what server is suggesting and it feels like we had 2 options from >>>> >>>>> the client end, either fail fast or let the server override the >>>> >>>>> client side config, it seemed like server overriding the client side >>>> >>>>> config with the client logging this as a warning is what i have >>>> >>>>> implemented mostly from pov what's done today for other configs. >>>> >>>>> I do think we should think a bit more about how server side >>>> >>>>> overrides go along with the client side configs (I understand this >>>> >>>>> is more client side implementation details than directly related >>>> >>>>> directly to server) and plan to start a thread discussing this more >>>> >>>>> in depth. I wanted to share a summary of this discussion (which is >>>> >>>>> captured in pr as well [here]) to keep the wider community aware. >>>> >>>>> >>>> >>>>> Please vote in the next 72 hours: >>>> >>>>> >>>> >>>>> [ ] +1 Add these changes to the spec >>>> >>>>> [ ] +0 >>>> >>>>> [ ] -1 I have questions and/or concerns >>>> >>>>> >>>> >>>>> Best, >>>> >>>>> Prashant Singh
