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

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.