Re: SQL Property Graph Queries (SQL/PGQ)
| От | Henson Choi |
|---|---|
| Тема | Re: SQL Property Graph Queries (SQL/PGQ) |
| Дата | |
| Msg-id | CAAAe_zDENQ3_V03-jcCVvup0OGB49KdwxdzeuudwUh=uKzVK9w@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: SQL Property Graph Queries (SQL/PGQ) (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>) |
| Ответы |
Re: SQL Property Graph Queries (SQL/PGQ)
|
| Список | pgsql-hackers |
2026년 1월 5일 (월) PM 1:15, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>님이 작성:
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.
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.
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.
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
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.
Best regards,
Henson
В списке pgsql-hackers по дате отправления: