agora inbox for pgsql-committers@postgresql.org
help / color / mirror / Atom feedpgsql: Disallow aggregates, window functions, and SRFs in GRAPH_TABLE C
2+ messages / 1 participants
[nested] [flat]
* pgsql: Disallow aggregates, window functions, and SRFs in GRAPH_TABLE C
@ 2026-08-05 08:57 Peter Eisentraut <peter@eisentraut.org>
0 siblings, 0 replies; 2+ messages in thread
From: Peter Eisentraut @ 2026-08-05 08:57 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Disallow aggregates, window functions, and SRFs in GRAPH_TABLE COLUMNS
The COLUMNS list of a GRAPH_TABLE query is parsed as an ordinary select
target list, which permits aggregate functions, window functions, and
set-returning functions. GRAPH_TABLE has no machinery to evaluate them,
though: the rewriter copies the COLUMNS target list verbatim into a
freshly built subquery whose hasAggs/hasWindowFuncs/hasTargetSRFs flags
are never set, so the planner builds no Agg/WindowAgg node (and no SRF
expansion) and the Aggref/WindowFunc/SRF reaches the executor. This
triggers an assertion failure ("ecxt_aggvalues != NULL"), or "Aggref
found in non-Agg plan node" on a non-assert build, for otherwise
parser-accepted SQL such as
SELECT max(c) FROM GRAPH_TABLE
(g MATCH (x IS v) COLUMNS (count(*) AS c));
Reject these constructs in transformRangeGraphTable() the same way
subqueries are already handled: save and clear pstate->p_hasAggs,
p_hasWindowFuncs, and p_hasTargetSRFs around the transformation of the
COLUMNS list, and raise a "not supported" error if any of them got set.
This is deliberately a blanket prohibition for now. Once quantified
element patterns such as (a)->{1,5} are supported, aggregates over
property references of higher degree (e.g. count(a) or sum(a.val)) can
be allowed; at that point the check will need to inspect the aggregate
arguments rather than reject all aggregates outright.
Author: Ewan Young <kdbase.hack@gmail.com>
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/CAON2xHOYAmYLkB2jGi6g77d6Fqv8YgOrfV-riQVf0K_7AdxD3w@mail....
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/f585671055d1c56d6fba0bc5835d28e68248ccfe
Modified Files
--------------
src/backend/parser/parse_clause.c | 30 ++++++++++++++++++++++++++++++
src/test/regress/expected/graph_table.out | 7 +++++++
src/test/regress/sql/graph_table.sql | 4 ++++
3 files changed, 41 insertions(+)
^ permalink raw reply [nested|flat] 2+ messages in thread
* pgsql: Disallow aggregates, window functions, and SRFs in GRAPH_TABLE C
@ 2026-08-05 08:57 Peter Eisentraut <peter@eisentraut.org>
0 siblings, 0 replies; 2+ messages in thread
From: Peter Eisentraut @ 2026-08-05 08:57 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Disallow aggregates, window functions, and SRFs in GRAPH_TABLE COLUMNS
The COLUMNS list of a GRAPH_TABLE query is parsed as an ordinary select
target list, which permits aggregate functions, window functions, and
set-returning functions. GRAPH_TABLE has no machinery to evaluate them,
though: the rewriter copies the COLUMNS target list verbatim into a
freshly built subquery whose hasAggs/hasWindowFuncs/hasTargetSRFs flags
are never set, so the planner builds no Agg/WindowAgg node (and no SRF
expansion) and the Aggref/WindowFunc/SRF reaches the executor. This
triggers an assertion failure ("ecxt_aggvalues != NULL"), or "Aggref
found in non-Agg plan node" on a non-assert build, for otherwise
parser-accepted SQL such as
SELECT max(c) FROM GRAPH_TABLE
(g MATCH (x IS v) COLUMNS (count(*) AS c));
Reject these constructs in transformRangeGraphTable() the same way
subqueries are already handled: save and clear pstate->p_hasAggs,
p_hasWindowFuncs, and p_hasTargetSRFs around the transformation of the
COLUMNS list, and raise a "not supported" error if any of them got set.
This is deliberately a blanket prohibition for now. Once quantified
element patterns such as (a)->{1,5} are supported, aggregates over
property references of higher degree (e.g. count(a) or sum(a.val)) can
be allowed; at that point the check will need to inspect the aggregate
arguments rather than reject all aggregates outright.
Author: Ewan Young <kdbase.hack@gmail.com>
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/CAON2xHOYAmYLkB2jGi6g77d6Fqv8YgOrfV-riQVf0K_7AdxD3w@mail....
Branch
------
REL_19_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/8ce749f8f65c8991d6d2f5010116530e0d7fb2ad
Modified Files
--------------
src/backend/parser/parse_clause.c | 30 ++++++++++++++++++++++++++++++
src/test/regress/expected/graph_table.out | 7 +++++++
src/test/regress/sql/graph_table.sql | 4 ++++
3 files changed, 41 insertions(+)
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-08-05 08:57 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-08-05 08:57 pgsql: Disallow aggregates, window functions, and SRFs in GRAPH_TABLE C Peter Eisentraut <peter@eisentraut.org>
2026-08-05 08:57 pgsql: Disallow aggregates, window functions, and SRFs in GRAPH_TABLE C Peter Eisentraut <peter@eisentraut.org>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox