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.
