I agree with Prashant's arguments.
This is a good thing to add and it can enable secure views with trusted
engines, but the catalog implementer and warehouse administrator (who sets
up trusted engine relationships) have higher responsibilities in
those cases. That's okay and catalogs can also rely
Agree, that ownership should be managed entirely by catalog, because we
don't define Actors / Users in IRC, and a catalog can very well store this
metadata separately (not necessarily in the view metadata obj), hence we
don't talk about owner in this proposal.
loaded-via / referenced-by needs to o
I believe that Ryan is correct, that the ownership and access should be
managed by the catalog.
Determining who has access for CRUD operations on the table data as well as
CRUD operations on the table metadata are rather complicated questions.
Adding Views to the mix is an exponential change in th
I think that ownership should be managed by the catalog and should not be
set by table properties. Respecting an "owner" property would easily lead
to security issues where writers can change the property with write access.
I think ownership or what role is the definer, like other security
attribut
Hi Prashant,
Thanks for sharing this proposal! This has been top of mind for me as well,
since I’m working on integrating Trino with Iceberg while also supporting other
heterogeneous engines in the ecosystem.
I agree that a change like this is necessary to enable SECURITY DEFINER views
to corr
Hi everyone,
I wanted to bring up a small but important change to how we handle view
security in Iceberg, especially for *DEFINER* views. This change is crucial
for ensuring views function as a secure gateway to sensitive data, where
access is determined by the view's creator, not the user running
