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

On Wed, Aug 5, 2026 at 2:30 PM Peter Eisentraut <peter(at)eisentraut(dot)org>
wrote:

> On 18.06.26 16:32, Ashutosh Bapat wrote:
> > The problem with aggregates and window functions is that there is not
> > enough context for performing aggregation in COLUMNs. Set returning
> > functions are different, they can be safely evaluated in queries that
> > replace the GRAPH_TABLE construct. Looking at the standard graph table
> > columns clause is a list of graph table column definitions, each of
> > which is a <value expression> which can be <collection value
> > expression>. So it looks like the standard doesn't prohibit SRFs in
> > COLUMNs clause and we are evaluating them correctly. However, I am
> > wondering whether GRAPH_TABLE is expected to output only one row for
> > every matching walk/substructure from the graph; there are GRAPH_TABLE
> > shapes that seem to suggest one row per matching pattern. SRFs violate
> > that rule. Maybe that's why they should be prohibited in COLUMNs. But
> > I don't think I have understood it well. Peter, can you please clarify
> > whether SRFs can be part of COLUMNs clause or not?
>
> I committed patch v2, which includes the prohibition of SRFs. If
> someone comes up with well-defined semantics for those, possibly
> supported by test cases, then we could re-enable them, but for now we
> don't have that, so it's better not to leave this enabled accidentally.
>
>
WFM.

--
Best Wishes,
Ashutosh Bapat