On Wed, Aug 5, 2026 at 2:30 PM Peter Eisentraut <[email protected]> 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
