Cypher、GQL、PGQL与SQL:2003 PGQ的通用查询子集是什么？

问题背景 #

Cypher查询语言因Neo4J得到普及，目前正被标准化为openCypher。openCypher官方提到过SQL/GQL，但GQL的官方站点最后一次更新是在2019年。另外，SQL:2023标准中包含了属性图查询章节，名为SQL/PGQ。可惜SQL:2003并未公开，相关细节只能靠推测。此外，由Oracle主导的PGQL似乎和SQL/PGQ一致，语法看起来像是Cypher的子集，但不同语言之间存在无法互通的表达式也很正常。

用户疑问 #

我猜测像MATCH (a:b {c:42})这类非常简单的查询表达式可以在所有这些语言中安全使用，但遇到复杂属性、带引号字符串、列表值、返回类型、限制等场景时呢？是否存在一个有正式定义的Cypher查询子集，能在这些语言中保持语义一致？

回答 #

目前并没有一个被openCypher、SQL/PGQ、PGQL等所有属性图查询语言共同认可并正式定义的通用Cypher子集，无法保证在所有场景下语义完全一致。具体差异和现状如下：

• 基础匹配的非正式兼容：像MATCH (a:b {c:42})这类最基础的节点标签匹配、简单属性过滤语法，确实在多数语言中能正常执行，但这只是行业实践中形成的非正式共识，没有统一的规范作为背书。
• 复杂场景的明显差异：
  • 字符串与列表：不同语言对带引号字符串的转义规则、列表的定义和操作语法存在差异，比如PGQL对列表的索引逻辑可能和openCypher不一致；
  • 返回类型：SQL/PGQ作为SQL标准的一部分，返回结果会贴合SQL的类型系统，而openCypher的返回类型逻辑更偏向图数据库原生的类型体系；
  • 限制与分页：LIMIT/SKIP这类语法虽然表面相似，但在不同实现中的执行逻辑（比如分页时的节点遍历顺序）可能存在语义差异；
• 标准层面的不确定性：GQL长期未更新，SQL/PGQ的细节由于标准文档限制难以完全掌握，PGQL和SQL/PGQ的一致性也未完全公开确认，这些因素都导致统一的兼容子集难以形成。

内容的提问来源于stack exchange，提问作者Jakob