Re: GRAPH_TABLE: aggregates/window/set-returning functions in COLUMNS crash the backend

On Tue, Jun 16, 2026 at 2:41 PM Ewan Young <kdbase(dot)hack(at)gmail(dot)com> wrote:
>
> Hi,
>
> While testing SQL/PGQ I found that putting an aggregate, window
> function, or set-returning function in the COLUMNS list of a
> GRAPH_TABLE query crashes the backend.
>
> Minimal reproducer:
>
> CREATE TABLE v (id int PRIMARY KEY);
> INSERT INTO v VALUES (1);
> CREATE PROPERTY GRAPH g VERTEX TABLES (v);
>
> SELECT max(c) FROM GRAPH_TABLE (g MATCH (x IS v) COLUMNS (count(*) AS c));
> On an assert-enabled build this trips
>
> TRAP: failed Assert("econtext->ecxt_aggvalues != NULL"),
> File: "execExprInterp.c", Line: 1969
> and on a non-assert build it fails at execution with
>
> ERROR: Aggref found in non-Agg plan node
> A window function in COLUMNS behaves the same way; a set-returning
> function is silently accepted and produces nonsensical results.
>
> Root cause: transformRangeGraphTable() (parser/parse_clause.c)
> transforms the COLUMNS expressions with EXPR_KIND_SELECT_TARGET, which
> permits aggregates, window functions and SRFs. GRAPH_TABLE has no
> machinery to evaluate them, though: rewriteGraphTable.c copies the
> COLUMNS target list verbatim into a freshly built subquery whose
> hasAggs/hasWindowFuncs flags are never set, so the planner builds no
> Agg/WindowAgg node and the Aggref/WindowFunc reaches the executor.
> (As a side effect p_hasAggs also leaks into the enclosing query,
> yielding spurious "must appear in the GROUP BY clause" errors for some
> other COLUMNS shapes.)
>
> These constructs are not meaningful in a GRAPH_TABLE COLUMNS list, so
> the attached patch rejects them at parse-analysis time, the same way
> every other non-aggregating context does. It adds a dedicated
> EXPR_KIND_GRAPH_TABLE_COLUMNS and wires it into the aggregate, window
> and set-returning-function checks, producing errors such as
>
> ERROR: aggregate functions are not allowed in GRAPH_TABLE COLUMNS
> Plain column references and subqueries are unaffected (subqueries
> continue to be rejected as before). A regression test is added to
> graph_table.sql, and "make check" passes.

Thanks for the report and the patch.

Right now we do not support quantified element patterns like
(a)->{1-5}, but when we do that it's allowed to have aggregates in
COLUMNs e.g. count(a) or sum(a.val). So the patch is not going in the
right direction. Instead we should check treat pstate->p_hasAggs and
pstate->p_hasWindowFuncs just like pstate->hasSublinks and throw an
error in transformRangeGraphTable() for now. When we will support
quantified element patterns, we will need to check the arguments of
the aggregates. If the arguments are property references with higher
degree, we will allow the aggregates, otherwise not.

--
Best Wishes,
Ashutosh Bapat