On 16.02.24 20:23, Andres Freund wrote:
> One aspect that I m concerned with structurally is that the transformation,
> from property graph queries to something postgres understands, is done via the
> rewrite system. I doubt that that is a good idea. For one it bars the planner
> from making plans that benefit from the graph query formulation. But more
> importantly, we IMO should reduce usage of the rewrite system, not increase
> it.
PGQ is meant to be implemented like that, like views expanding to joins
and unions. This is what I have gathered during the specification
process, and from other implementations, and from academics. There are
certainly other ways to combine relational and graph database stuff,
like with native graph storage and specialized execution support, but
this is not that, and to some extent PGQ was created to supplant those
other approaches.
Many people will agree that the rewriter is sort of weird and archaic at
this point. But I'm not aware of any plans or proposals to do anything
about it. As long as the view expansion takes place there, it makes
sense to align with that. For example, all the view security stuff
(privileges, security barriers, etc.) will eventually need to be
considered, and it would make sense to do that in a consistent way. So
for now, I'm working with what we have, but let's see where it goes.
(Note to self: Check that graph inside view inside graph inside view ...
works.)