Thanks a ton everyone the vote is passed with : 15 +1 (6 binding and 9 non-binding) with 0 -1s (standing)
I will start working towards cleaning the reference impl i has with spark as client to this approved spec ~ Thanks, Prashant Singh On Fri, Feb 6, 2026 at 2:32 PM Ryan Blue <[email protected]> wrote: > Changing my vote to +1 since the separator has been addressed and the > referenced-by discussion looks like we've concluded. Thanks! > > On Fri, Jan 30, 2026 at 4:49 PM Russell Spitzer <[email protected]> > wrote: > >> No problem, I know we’ve been going back on this one for a while so it’s >> been a bit confusing >> >> On Fri, Jan 30, 2026 at 6:07 PM Daniel Weeks <[email protected]> wrote: >> >>> Thanks for the clarification Russel and Prashant. >>> >>> My initial concern was that we were introducing the definer/invoker >>> constructs and assuming the trust relationship through the spec language, >>> but it looks like we reference that in the PR description and discussion >>> but not the spec language itself. At some point we need to address the >>> intended usage here because the primary usage was within the context of the >>> trust relationship (other usage like auditing seems a secondary >>> motiviation). >>> >>> Apologies for the confusion and I'll happily retract my -1. >>> >>> -Dan >>> >>> >>> >>> On Fri, Jan 30, 2026 at 2:29 PM Prashant Singh <[email protected]> >>> wrote: >>> >>>> Thank you for the feedback Ryan, I will update the separator in this >>>> case to be the namespace separator ! I will do more research on other >>>> feedback. >>>> >>>> Thanks for the feedback Dan, >>>> >>>> Agree with Russell here, I believe the whole reason why we wanted to >>>> have a referenced-by chain is to give the catalog the complete context of >>>> how to Authorize and since IRC don't go in the world of AuthZ >>>> we thought just let the catalog do what they wanna do with >>>> referenced-by, we are *not* defining actions what we want the catalog >>>> to take in the spec. >>>> We have additionally discussed this in the DISCUSS thread too [1]. >>>> >>>> Definitely for the E2E picture for making this work we need *Trusted >>>> Engine,* *OWNER* privilege and then *AuthZ* to correctly give read >>>> access to the table, but these are purely Catalog side constructs based on >>>> AuthZ. >>>> The simplest rationale of allowing this to be sent from the client to >>>> server apart from DEFINER view is to help in audit as well. >>>> >>>> Please let us know if it helps address your concerns. >>>> >>>> [1] https://lists.apache.org/thread/01gb9rygdd1gqks7lnl1o6440qocnh9m >>>> >>>> Best, >>>> Prashant Singh >>>> >>>> On Fri, Jan 30, 2026 at 1:03 PM Russell Spitzer < >>>> [email protected]> wrote: >>>> >>>>> @Daniel I believe we talked about this only working in a situation >>>>> where the client and catalog have already pre-established a trusted >>>>> relationship. This was brought up again on the PR a few days ago, >>>>> https://github.com/apache/iceberg/pull/13810#issuecomment-3816022525 >>>>> and Prashant posted links again to the original thinking there. >>>>> >>>>> Wouldn't this mean that you just can't give access to a client which >>>>> can make arbitrary calls against your catalog? >>>>> >>>>> If a client can fake a request to the catalog, then why wouldn't it >>>>> just ask for the table through the view directly, get the files (ignoring >>>>> the view) and then read the table? >>>>> >>>>> On Fri, Jan 30, 2026 at 2:30 PM Daniel Weeks <[email protected]> >>>>> wrote: >>>>> >>>>>> I'm going to have to update my comment to -1. >>>>>> >>>>>> Based on some of the discussion in the PR, I went back and reviewed >>>>>> the discussion and I don't think this approach works based on some >>>>>> comments >>>>>> I made in the recording (link with timestamp >>>>>> <https://youtu.be/orAXA5e9pmU?si=CjIEQk__dcTWcdEi&t=1438> and again >>>>>> here <https://youtu.be/orAXA5e9pmU?si=tvpIN6ytIu2JU_fj&t=1902>). >>>>>> >>>>>> The main issue I see is that we're not enabling a secure way to do >>>>>> this because we cannot trust the client to provide the surrounding view. >>>>>> What would prevent a client from just addressing a defender view in a >>>>>> load >>>>>> table and accessing data the invoker should not have access to? >>>>>> >>>>>> I feel like there are security implications here that we haven't >>>>>> properly addressed. >>>>>> >>>>>> -Dan >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Jan 30, 2026 at 8:52 AM Ryan Blue <[email protected]> wrote: >>>>>> >>>>>>> -1 for now (will probably change) >>>>>>> >>>>>>> I think that there is a problem in that a dot is used to separate >>>>>>> the namespace (which uses namespace separator) from the table name. If >>>>>>> my >>>>>>> namespace separator is `|` then it would require `name|space.table`. Why >>>>>>> not use the same separator between the namespace and table name? If we >>>>>>> use >>>>>>> `.` then the last namespace part cannot have a `.`, which is an odd >>>>>>> restriction. >>>>>>> >>>>>>> On Thu, Jan 29, 2026 at 12:07 PM Daniel Weeks <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> +1 (binding) >>>>>>>> >>>>>>>> Minor comments on the Spec PR. I'm assuming everyone is voting >>>>>>>> specifically on the spec changes, but just want to clarify >>>>>>>> (implementation >>>>>>>> PR will go through normal review process). >>>>>>>> >>>>>>>> -Dan >>>>>>>> >>>>>>>> On Thu, Jan 29, 2026 at 9:38 AM Steve <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> +1 (non-binding) >>>>>>>>> >>>>>>>>> On Thu, Jan 29, 2026 at 12:57 AM Alexandre Dutra < >>>>>>>>> [email protected]> wrote: >>>>>>>>> > >>>>>>>>> > +1 (non-binding) >>>>>>>>> > >>>>>>>>> > Thanks, >>>>>>>>> > Alex >>>>>>>>> > >>>>>>>>> > Le jeu. 29 janv. 2026 à 08:19, Bharath Krishna < >>>>>>>>> [email protected]> a écrit : >>>>>>>>> >> >>>>>>>>> >> +1, that was a missing piece for view authorization! >>>>>>>>> >> >>>>>>>>> >> On 2026/01/29 07:03:31 roryqi wrote: >>>>>>>>> >> > +1, excited to see this. I am working on related work about >>>>>>>>> Apache Gravitino. >>>>>>>>> >> > >>>>>>>>> >> > Christian Thiel <[email protected]> 于2026年1月29日周四 >>>>>>>>> 14:50写道： >>>>>>>>> >> > > >>>>>>>>> >> > > +1 (non-binding) >>>>>>>>> >> > > >>>>>>>>> >> > > Gábor Kaszab <[email protected]> schrieb am Do. 29. >>>>>>>>> Jan. 2026 um 07:22: >>>>>>>>> >> > >> >>>>>>>>> >> > >> +1 (nb) >>>>>>>>> >> > >> >>>>>>>>> >> > >> Gábor >>>>>>>>> >> > >> >>>>>>>>> >> > >> On Thu, 29 Jan 2026, 00:02 Adnan Hemani via dev, < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >> > >>> >>>>>>>>> >> > >>> +1 (non-binding) >>>>>>>>> >> > >>> >>>>>>>>> >> > >>> On Wed, Jan 28, 2026 at 10:17 AM Steven Wu < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >> > >>>> >>>>>>>>> >> > >>>> +1 >>>>>>>>> >> > >>>> >>>>>>>>> >> > >>>> On Wed, Jan 28, 2026 at 8:02 AM Russell Spitzer < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >> > >>>>> >>>>>>>>> >> > >>>>> +1 >>>>>>>>> >> > >>>>> >>>>>>>>> >> > >>>>> On Wed, Jan 28, 2026 at 10:01 AM Eduard Tudenhöfner < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >> > >>>>>> >>>>>>>>> >> > >>>>>> +1 >>>>>>>>> >> > >>>>>> >>>>>>>>> >> > >>>>>> On Tue, Jan 27, 2026 at 6:29 PM Prashant Singh < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >> > >>>>>>> >>>>>>>>> >> > >>>>>>> Hello everyone ! >>>>>>>>> >> > >>>>>>> The namespace separator for nested namespaces >>>>>>>>> discussion is converged (thanks a ton Eduard) >>>>>>>>> >> > >>>>>>> I additionally also added wording for the nested >>>>>>>>> views per the feedback. >>>>>>>>> >> > >>>>>>> The spec proposal [1] is ready for review again, I >>>>>>>>> have also updated the reference implementation too from client side >>>>>>>>> [2] per >>>>>>>>> spec. >>>>>>>>> >> > >>>>>>> >>>>>>>>> >> > >>>>>>> Please do have a pass and vote based on how you all >>>>>>>>> feel, when you get some time. Appreciate all the feedback so far ! >>>>>>>>> >> > >>>>>>> >>>>>>>>> >> > >>>>>>> [1] https://github.com/apache/iceberg/pull/13810 >>>>>>>>> >> > >>>>>>> [2] https://github.com/apache/iceberg/pull/13979 >>>>>>>>> >> > >>>>>>> >>>>>>>>> >> > >>>>>>> Best, >>>>>>>>> >> > >>>>>>> Prashant Singh >>>>>>>>> >> > >>>>>>> >>>>>>>>> >> > >>>>>>> >>>>>>>>> >> > >>>>>>> >>>>>>>>> >> > >>>>>>> On Fri, Sep 5, 2025 at 10:04 AM Prashant Singh < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >> > >>>>>>>> >>>>>>>>> >> > >>>>>>>> Thanks for the feedback, Ryan. I agree that we >>>>>>>>> should leave the vote open longer and get the wording right. I'll >>>>>>>>> work on >>>>>>>>> addressing the new feedbacks. >>>>>>>>> >> > >>>>>>>> >>>>>>>>> >> > >>>>>>>> Best, >>>>>>>>> >> > >>>>>>>> Prashant Singh >>>>>>>>> >> > >>>>>>>> >>>>>>>>> >> > >>>>>>>> On Fri, Sep 5, 2025 at 8:59 AM Ryan Blue < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >> > >>>>>>>>> >>>>>>>>> >> > >>>>>>>>> I think this is a good addition, but I think it may >>>>>>>>> need a bit of work to get the wording right and there's still ongoing >>>>>>>>> discussion. Maybe we should leave this vote open longer until the >>>>>>>>> discussion settles? >>>>>>>>> >> > >>>>>>>>> >>>>>>>>> >> > >>>>>>>>> Also, I want to point out that this is another use >>>>>>>>> of a specific separator char. I think it would be good to revisit our >>>>>>>>> separator discussion and finally close on it. >>>>>>>>> >> > >>>>>>>>> >>>>>>>>> >> > >>>>>>>>> On Fri, Sep 5, 2025 at 12:33 AM John Zhuge < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >> > >>>>>>>>>> >>>>>>>>> >> > >>>>>>>>>> +1 (non-binding) >>>>>>>>> >> > >>>>>>>>>> >>>>>>>>> >> > >>>>>>>>>> On Thu, Sep 4, 2025 at 6:23 PM Yufei Gu < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >> > >>>>>>>>>>> >>>>>>>>> >> > >>>>>>>>>>> +1 on the spec change. It’s a solid first step >>>>>>>>> toward enabling DEFINER views. As usual, the spec change is >>>>>>>>> intentionally >>>>>>>>> kept separate from access control. >>>>>>>>> >> > >>>>>>>>>>> >>>>>>>>> >> > >>>>>>>>>>> Yufei >>>>>>>>> >> > >>>>>>>>>>> >>>>>>>>> >> > >>>>>>>>>>> >>>>>>>>> >> > >>>>>>>>>>> On Wed, Sep 3, 2025 at 8:18 AM huaxin gao < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >> > >>>>>>>>>>>> >>>>>>>>> >> > >>>>>>>>>>>> +1 (non-binding) >>>>>>>>> >> > >>>>>>>>>>>> >>>>>>>>> >> > >>>>>>>>>>>> On Tue, Sep 2, 2025 at 6:38 PM Prashant Singh < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >> > >>>>>>>>>>>>> >>>>>>>>> >> > >>>>>>>>>>>>> Hi All, >>>>>>>>> >> > >>>>>>>>>>>>> I propose adding an optional referenced-by to >>>>>>>>> the REST loadTable call, which will contain the fully qualified name >>>>>>>>> of the >>>>>>>>> view (namespace of the view name and the view name) in case the table >>>>>>>>> is >>>>>>>>> being referenced by a view. >>>>>>>>> >> > >>>>>>>>>>>>> >>>>>>>>> >> > >>>>>>>>>>>>> This will be really helpful in a couple of ways >>>>>>>>> : >>>>>>>>> >> > >>>>>>>>>>>>> 1. First step towards enabling DEFINER views >>>>>>>>> >> > >>>>>>>>>>>>> 2. Audit, incase one wants to track what's the >>>>>>>>> base objects accessed from the direct object accessed (example: doc) >>>>>>>>> >> > >>>>>>>>>>>>> >>>>>>>>> >> > >>>>>>>>>>>>> For details please check: >>>>>>>>> >> > >>>>>>>>>>>>> >>>>>>>>> >> > >>>>>>>>>>>>> - Spec change PR: >>>>>>>>> https://github.com/apache/iceberg/pull/13810 >>>>>>>>> >> > >>>>>>>>>>>>> - Reference Implementation PR: >>>>>>>>> https://github.com/apache/iceberg/pull/13979 >>>>>>>>> >> > >>>>>>>>>>>>> - Discuss Thread: >>>>>>>>> https://lists.apache.org/thread/01gb9rygdd1gqks7lnl1o6440qocnh9m >>>>>>>>> >> > >>>>>>>>>>>>> >>>>>>>>> >> > >>>>>>>>>>>>> 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 >>>>>>>>> >> > >>>>>>>>>> >>>>>>>>> >> > >>>>>>>>>> >>>>>>>>> >> > >>>>>>>>>> >>>>>>>>> >> > >>>>>>>>>> -- >>>>>>>>> >> > >>>>>>>>>> John Zhuge >>>>>>>>> >> > >>>>>>>>> >>>>>>>>
