On Fri, Jan 2, 2026 at 6:53 PM Henson Choi <assam258@gmail.com> wrote: > > When I raise issues about differences from Cypher, even when I sense my suggestions > might be overreaching, I do so for two reasons: (a) I don't have access to the > SQL/PGQ standard document, and (b) my implementation-level experience is primarily > with Cypher. However, if I feel this dissonance, users coming from Cypher will > likely experience the same confusion. I hope you'll consider this user perspective > valuable, even when the technical decisions differ.
I think all these issues are worth raising on pgsql-hackers. Many users who are using Cypher may want to use PostgreSQL + SQL/PGQ as their graph database. All these inputs are valuable. Let me summarise my thoughts briefly over here.
Thank you for the encouraging response. I'm glad the Cypher user perspective is considered valuable.
IMO, at a higher level, we could leverage Apache/AGE-like extensions to provide Cypher compatibility on top of SQL/PGQ. The required functionality from SQL/PGQ (directly or indirectly) can be implemented in the core. For example, the core will throw an error when a label is not defined, but Apache/AGE may detect such labels beforehand, avoid translating the query to SQL/PGQ and return 0 rows in such a case. Or Apache/AGE may add stable functions for labels() and property_names(), but use SQL/PGQ catalogs for implementation.
This makes sense. The layered approach with extensions handling compatibility concerns on top of SQL/PGQ core functionality seems pragmatic.
I envision the relation between Apache/AGE and SQL/PGQ evolving similarly to how the relation between pg_partman and built-in partitioning evolved. Others may have different opinions. We may even want to weigh each feature/functionality separately. How to support Cypher queries on PostgreSQL in the context of SQL/PGQ seems to be a broader topic worth a discussion of its own.
I appreciate this perspective. I'll continue to raise issues where I notice differences from Cypher, particularly from a user experience standpoint. However, I fully respect that the community will make the final decisions on these matters, weighing standard compliance, implementation complexity, and PostgreSQL's design principles.
-- Best Wishes, Ashutosh Bapat
Regarding the retesting you mentioned earlier - apologies for the delay. I've been caught up with work commitments at my company, but I'll get back to it as soon as possible.
Looking forward to contributing to this broader discussion.
