Adding support for SQL/PGQ syntax
Hi there,
I'd like to propose adding support for the new Property Graph Queries (SQL/PGQ) syntax from the SQL:2023 standard to libpg_query.
Background
SQL/PGQ introduces a visual graph syntax to make pattern matching and path-finding on graph data easier. As part of developing DuckPGQ, a popular DuckDB extension, we have already implemented a significant portion of the SQL/PGQ grammar in our own fork of libpg_query.
You can find our current implementation here: https://github.com/cwida/duckdb-pgq/blob/main/third_party/libpg_query/grammar/statements/pgq.y
Proposal
I would be happy to work on a pull request to contribute this implementation upstream to libpg_query.
I'm aware that PostgreSQL has its own SQL/PGQ support in development (as discussed here). My implementation could serve as a solid starting point, and we can of course align it with the official PostgreSQL version as it becomes finalized.
This issue is intended to gauge interest and discuss the best path forward. I think native SQL/PGQ support would be a fantastic addition, making it easier for the many systems that rely on libpg_query to adopt the new standard.
Would you be open to a contribution for this feature?
Let me know your thoughts!
Kind regards,
Daniel ten Wolde
Hi @Dtenwolde,
Thanks for opening the issue and inquiring on this!
Any addition to the grammar that is specific to libpg_query (vs upstream Postgres) has to be viewed in light of maintenance effort, similar to the comment I made recently in regards to adding support for YugabyteDB specific syntax.
A few thoughts, keeping in mind how adding SQL/PGQ support differs to the YugabyteDB syntax request:
- SQL/PGQ requires multiple new node structs to be added to be useful, and those may be different than what Postgres ultimately adds (so we would have a breaking change at that point - which is not the end of the world, but not great either)
- SQL/PGQ adds multiple keywords in the core grammar in regular queries, so I'm worried about shift/reduce type errors when rebasing on new Postgres versions that themselves carry grammar changes (unrelated to SQL/PGQ)
- It appears the forked version you shared is based on the DuckDB variant of libpg_query (which diverged some time ago), not on the current libpg_query upstream version (which is currently mainly focused on query syntax that Postgres itself supports, with very minor deviations to support pg_stat_statements normalized query text) -- so its not clear how modifying upstream libpg_query helps here (vs getting DuckDB core to modify their version)
Based on this, I don't think its a good idea to add support for SQL/PGQ to libpg_query at this point. Happy to discuss/be convinced otherwise of course, especially if I missed/misinterpreted something.