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 <[email protected]>
Reviewed-by: Ashutosh Bapat <[email protected]>
Discussion:
https://www.postgresql.org/message-id/flat/caon2xhoyamylkb2jgi6g77d6fqv8ygorfv-riqvf0k_7adx...@mail.gmail.com
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(+)
