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.)
