rdblue commented on code in PR #13810:
URL: https://github.com/apache/iceberg/pull/13810#discussion_r2747514531
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -980,6 +980,30 @@ paths:
schema:
type: string
enum: [ all, refs ]
+ - in: query
+ name: referenced-by
+ description:
+ A comma-separated list of fully qualified view names (namespace
and view name) representing the view
+ reference chain when a table is loaded via a view. The list should
be ordered with the outermost view
Review Comment:
I think I was there, but I don't remember there being a specific conclusion
to that question. I think we need to be clear about exactly what this is for
before moving forward so that we know that this requires the full reference
list.
If I understand correctly, the idea is that you have a nested view that is
run as INVOKER within a view run as DEFINER. If the inner view were run as
DEFINER, we would not need any references from outside of that view because it
is self-contained, so it must be that we have an INVOKER within a DEFINER. Then
the question is how to handle the inner INVOKER: is the definer of the outer
view considered the invoker of the inner view? If so, we need to know about the
outer view.
This may seem like an obvious choice, but always using the access privileges
from the original query is [how PostgreSQL
works](https://www.postgresql.org/docs/current/sql-createview.html):
> If the view has the security_invoker property set to true, access to the
underlying base relations is determined by the permissions of the user
executing the query, rather than the view owner. Thus, the user of a security
invoker view must have the relevant permissions on the view and its underlying
base relations.
>
> If any of the underlying base relations is a security invoker view, it
will be treated as if it had been accessed directly from the original query.
Thus, a **security invoker view will always check its underlying base relations
using the permissions of the current user, even if it is accessed from a view
without the security_invoker property**.
If we used this interpretation, that the INVOKER is not context-dependent,
then we would have a simpler spec and behavior (DEFINER=definer's permissions,
INVOKER=query permissions), but at the cost of removing flexibility for catalog
implementers.
I'm trying to think whether this is a situation where the simpler option
would be too restrictive. I think the case where you would want to leave the
inner view as INVOKER is when you want both INVOKER and DEFINER behavior when
accessed directly (INVOKER) and indirectly (DEFINER). That seems like a weird
pattern with easy work-arounds to me: if you want to delegate when accessing
indirectly, you can embed the INVOKER view SQL in the DEFINER view.
I think I'd vote for the simpler option, but I'm interested in a bit more
discussion on this before we finalize it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
