Re: SQL Property Graph Queries (SQL/PGQ)
| От | Ashutosh Bapat |
|---|---|
| Тема | Re: SQL Property Graph Queries (SQL/PGQ) |
| Дата | |
| Msg-id | CAExHW5u8FhriXtRemrPjR=8L=mB6rsmsne=L5h0HBRb54-CGZA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: SQL Property Graph Queries (SQL/PGQ) (Henson Choi <assam258@gmail.com>) |
| Ответы |
Re: SQL Property Graph Queries (SQL/PGQ)
|
| Список | pgsql-hackers |
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. 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. 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. -- Best Wishes, Ashutosh Bapat
В списке pgsql-hackers по дате отправления: