Re: Authorization semantics and candidate pruning in GRAPH_TABLE

Hello,

On 08/09/2026 06:49, Wataru Naotsuka wrote:
>
> Hello pgsql-hackers,
>
> I would like to ask about authorization behavior for unlabeled
> patterns in Property Graph / GRAPH_TABLE, in particular whether the
> current permission error behavior is an intentional authorization
> semantic or mainly a consequence of the current rewrite implementation.
>
> As I understand it, a user executing GRAPH_TABLE needs SELECT
> privileges on the property graph itself, as well as on the underlying
> base relations that are actually referenced. I also understand the
> motivation for using security-invoker semantics, in order to avoid
> unintended privilege escalation through the graph owner's privileges.
>
> However, unlabeled patterns seem to have an interesting consequence.
>
> My understanding of the current rewrite flow is roughly:
>
> |candidate ↓ does it form a valid path? ├─ no → does not remain as a
> Query/RTE └─ yes → generate RTE → permission check|
>
> For example, suppose the possible vertex candidates are A, B, and C.
> The current user has SELECT privilege on A and C, but not on B.
>
> If a path containing B is structurally valid and therefore rewritten
> into an RTE, the entire query appears to fail with|permission denied|,
> even if that path would never actually return any rows.
>
> The first thing I would like to clarify is whether the following
> behavior is intentional:
>
> If any valid path candidate internally generated by unlabeled
> expansion contains an element for which the current user lacks the
> required privilege, the entire query is rejected.
>
> Is this an intended authorization semantic, or is it primarily a
> consequence of applying the normal RTE permission checks to the
> current rewrite result?
>
> I would also be interested to know whether SQL/PGQ or the SQL standard
> provides any requirement or guidance on this point.
>
>
> Relation to future candidate pruning
>
> One reason I am interested in clarifying this now is that I think
> there is room for more static candidate pruning before DFS or during
> path generation, in order to reduce the combinatorial explosion of
> possible path candidates.
>
In addition to what Ashutosh said, there's a proposed patch for early
pruning for path generation [1] (in case you missed it), delayed until
later advancements in SQL/PGQ state.
>
> Even today, candidates that cannot form a structurally valid path are
> not retained as final Query/RTEs. In the future, it may also be
> possible to eliminate candidates earlier based on information such as
> available properties or WHERE predicates.
>
> For example, suppose a future optimization reduces:
>
> |[A, B(!permitted), C] ↓ static pruning [C] ↓ DFS → Query / RTE|
>
> Before such an optimization, B may be materialized as an RTE and
> cause|permission denied|. After the optimization, B may disappear
> before RTE generation, and the same query may succeed.
>
> What I would especially like to avoid is a situation where, for
> semantically equivalent queries, whether|permission denied|is raised
> depends on implementation details of the rewrite, such as which
> candidates happen to be eliminated before RTE generation.
>
> For that reason, I wonder whether it would be better to establish the
> authorization boundary explicitly before introducing more
> candidate-pruning optimizations.
>
> I see two broad possibilities.
>
> *1. Make all-or-error an explicit semantic*
>
> |[A, B(!permitted), C] ↓ authorization permission denied|
>
> Privileges would be checked against the semantic candidate set before
> optimization. If any required element is not accessible, the query
> would fail.
>
> This would preserve the current behavior while making the
> authorization result independent of later candidate pruning.
>
> *2. Filter candidates by the current user's privileges first*
>
> |[A, B(!permitted), C] ↓ authorization-based filtering [A, C] ↓ static
> pruning [C] ↓ DFS → Query / RTE|
>
> Personally, I am interested in exploring this direction.
>
> Under this model, GRAPH_TABLE could be viewed as querying the part of
> the graph visible to the current user. If authorization determines the
> candidate set first, then later pruning based on connectivity,
> properties, WHERE predicates, or other static information would be
> less likely to affect authorization behavior.
>
> This filtering step would also reduce the number of candidates passed
> to DFS. As a possible future step, I would like to explore
> optimizations such as eliminating an element candidate early when a
> property referenced by a restrictive predicate is known not to exist
> on that element. I am not proposing that optimization in this
> discussion; my main goal here is to clarify the authorization boundary
> first.
>
I think a case like GRAPH_TABLE(g MATCH (a)-[e]->(b) COLUMNS (1))
retuning no rows because b's only path element was pruned is counter
intuitive (well this introduces again the "visible subgraph" part),
compared to failing and saying we didn't have access to the element table.
>
> Of course, visible-subgraph semantics also has trade-offs.
> Reachability, shortest paths, aggregates, and similar results may
> differ depending on which part of the graph is visible to the current
> user, so such semantics would need to be clearly defined and documented.
>
> There are also related questions that would need further discussion,
> for example:
>
> *
>
> whether the same visible-subgraph semantics should apply when
> labels are explicitly specified, or only for unlabeled expansion;
>
> *
>
> how column-level SELECT privileges should be handled;
>
> *
>
> and where exactly such authorization filtering should occur in the
> rewrite pipeline.
>
> I am not proposing security-definer semantics or using the graph
> owner's privileges to access underlying tables. I agree with the
> motivation for security-invoker behavior. The question I am interested
> in is instead at what stage the set of elements visible to the current
> user should be determined.
>
> If the current all-or-error behavior is intentional, I would like to
> understand the reasoning and would then consider making authorization
> explicit before candidate pruning.
>
> If, on the other hand, the current behavior is mainly a consequence of
> the rewrite implementation and permission-based candidate filtering
> would be acceptable, I would be interested in exploring that as a
> first step toward more general static candidate pruning.
>
> I would appreciate any thoughts on the intended authorization
> semantics here, especially regarding SQL/PGQ and what authorization
> boundary would be preferable in view of future rewrite optimizations.
>
I interpreted Subclause 9.5 (Converting a tabular property graph to a
pure property graph) of the standard as: The pure property graph is
generated from all vertex tables and all edge tables defined in the
tabular property graph descriptor, across all rows. So i don't think we
can think of something like "visible subgraph" by definition, maybe.

[1] :
https://www.postgresql.org/message-id/flat/CAEG8a3%2B4tA%3De2M_f%3DdfaMgur%2BHJQ4R11v0torj2nc_k8XX3U6A%40mail.gmail.com

Regards,
Ayoub