Re: SQL Property Graph Queries (SQL/PGQ)

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-02-16T19:23:01Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Fix some typos and make small stylistic improvements

  2. Cleanup users and roles in graph_table_rls test

  3. Dump labels in reproducible order

  4. SQL Property Graph Queries (SQL/PGQ)

  5. Factor out constructSetOpTargetlist() from transformSetOperationTree()

  6. Sort out table_open vs. relation_open in rewriter

  7. Rename grammar nonterminal to simplify reuse

  8. Make ecpg parse.pl more robust with braces

  9. Don't lock partitions pruned by initial pruning

  10. Remove pg_regex_collation

  11. Use auxv to check for CRC32 instructions on ARM.

  12. Fix inappropriate uses of atol()

  13. Remove unnecessary array object_classes[] in dependency.c

Hi,

On 2024-02-16 15:53:11 +0100, Peter Eisentraut wrote:
> The patch is quite fragile, and treading outside the tested paths will
> likely lead to grave misbehavior.  Use with caution.  But I feel that
> the general structure is ok, and we just need to fill in the
> proverbial few thousand lines of code in the designated areas.

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.

Greetings,

Andres Freund