Just to re-up my comments from the discussion.

I'm in favor of Immediate Parent only. Full chain seems to be for
situations where we want to be able to "override" the security
definition of an inner nested view. For users who want to
do this, I would encourage them to just make a brand new definer view
without referencing the "invoker" view.

For example

DEFINER => INVOKER => TABLE

The "definer" should not be able to remove the "invoked" nature of access
to the table. If a user really
wants that behavior they should construct

DEFINER (Combined with INVOKER SQL) => TABLE

I'd rather we didn't encourage more complicated constructions

On Mon, Feb 2, 2026 at 12:34 PM Prashant Singh <[email protected]>
wrote:

> Hi everyone,
>
> I’m currently working on passing additional context via the referenced-by
> parameter in loadTable calls. This is a foundational step toward enabling
> catalogs to make authorization decisions based on query execution context.
>
> While the broader trust relationships and AuthZ constructs are outside the
> scope of IRC, I’d like to align on the level of detail we should provide.
> Specifically: *Should we send the entire view reference chain, or only
> the immediate parent view on nested views?*
>
> The following are trade-offs:
>
>    -
>
>    *Full Chain:* Provides maximum flexibility for the server to make
>    complex AuthZ decisions but increases client-side overhead for tracking
>    nested references.
>    -
>
>    *Immediate Parent:* Simpler for the client to implement but provides
>    limited context for sophisticated authorization policies.
>
> *Prior Art & Research:* As noted in this discussion
> <https://github.com/apache/iceberg/pull/13810#discussion_r2747121401>
> (thanks Ryan and Russell), Postgres handles this via DEFINER (owner
> permissions) and INVOKER (query permissions) without requiring deeply
> nested context. My research into other engines hasn't yielded a standard
> "gold level" approach yet, as some platforms simply restrict nested view
> complexity.
>
> I’d love to hear your thoughts on which approach aligns better.
>
> Best regards,
>
> Prashant Singh
>

Reply via email to