Re: Disallow outer-level and WHERE-clause aggregates in GRAPH_TABLE

Melanie Plageman <melanieplageman(at)gmail(dot)com> writes:
> RMT is wondering if the ongoing work on this is an enhancement for 20
> or proposed work for 19. Does Ashutosh's reply satisfy Tom and Sami's
> concerns with the design. Is there work here that is still being
> proposed for v19 and is there consensus on it?

TBH, I stopped paying attention to this thread after I saw Andres'
concerns about PGQ [1]. I figured there was no chance of PGQ not
getting reverted for 19, so it wasn't urgent to fix this aspect
of it. Hence, I don't have an immediate answer on whether this is
a good-enough fix.

I will say that I do not like GraphPropertyRef one bit and that the
best way forward if we're not building an emergency band-aid for 19
is to get rid of it. "We have to deal with this everyplace we deal
with Vars" is not an appetizing prospect. I did realize after the
initial discussion that we already have a binding for Vars pointing at
the RTE_GRAPH_TABLE RTE, so we can't commandeer that representation
for what GraphPropertyRef represents. But there's more than one way
to skin that cat. The next idea I'd propose is to create a second RTE
of a different RTEKind, and then replace GraphPropertyRefs with Vars
pointing at that one. This would be kind of analogous to RTE_GROUP
Vars, or at least that's a handy precedent.

regards, tom lane

[1] https://www.postgresql.org/message-id/flat/dqa5mstx5mna3i7s23pdwl4m6bek7gqsgfccef44wjpswizufi%403aa6vzri3cat