Cypher查询语言已经在Neo4J中流行，并被标准化为openCypher.openCypher页面提到了SQL/GQL，但GQL page最后一次更新是在2019年.SQL:2023标准包括一个名为SQL/PGQ的section on Property Graph queries.遗憾的是，SQL:2003不是公开的，所以我只能猜测细节.然后是PGQL，由Oracle驱动，所以PGQL seems与SQL/PGQ相同，它的语法looks like是Cypher的子集，但我不会惊讶地发现每种语言中的表达式不能在其他语言中使用.
我假设very个简单的查询表达式(如MATCH (a:b {c:42}))可以安全地在所有这些语言中使用，但更复杂的属性、带引号的字符串、列表值、返回类型、限制等呢？在这些查询语言中，是否存在一个安全且正式定义的Cypher查询子集，具有相同语义？
我是Oracle的一名开发人员，一直在领导PGQL工作，最近我专注于Oracle数据库中的SQL/PGQ实现.
你给出的例子(MATCH (a:b {c:42}))是有效的Cypher，但不是有效的SQL或PGQL.
SQL将其标准化为MATCH (a IS b WHERE a.c = 42).
这里，a是顶点变量声明，b是由关键字IS引入的标签表达式，a.c = 42是引用顶点a的属性c的搜索条件.
是否存在安全和正式定义的Cypher查询子集， 这些查询语言之间的语义相同？
在所有这些语言中，没有一个(完整的)查询是有效的，如果只是因为SQL查询使用SELECT(或COLUMNS)，而Cypher使用RETURN和WITH.
但是，当只关注图模式匹配时，所有这些语言之间都有显著的重叠，并且差异大多是微小的和语法上的，因此它们之间的迁移变得很容易.顺便说一句，SQL/PGQ specification在技术上是公开的，但访问它确实需要付费.GQL一旦发布here也是如此.
但是不同的供应商将发布他们自己实现的文档.以下是Oracle数据库的最佳参考:
在图形模式匹配之外，语言之间没有太多的重叠.
在SQL中，由于图是表顶部的视图对象，用户对图的底层表执行INSERT/UPDATE/DELETE操作.例如，您可以查询一个图表，并将其插入到其底层表中，如下所示:INSERT INTO ... FROM GRAPH_TABLE ( my_graph MATCH ... )
在SQL中，属性是静态类型的，但有JSON(和XML)来处理半 struct 化数据，它可以很容易地与属性图结合.例如，属性图查询中的JSON点标记访问如下:MATCH (v IS person) WHERE v.address.street_name = 'Monroe Avenue'.
SQL包括许多重要的数据库功能，这些功能并不特定于图形，但对图形用户来说不是必不可少的:特权、约束、触发器、视图、丰富的数据类型集以及伴随的表达式和谓词等等.根据我们的项目经验，创建一个好的图形模型所需的大部分数据准备都是在SQL中非常有效地完成的.很多语言都缺乏这种功能，而这些语言并没有像SQL那样存在.
对于PGQL，SQL/PGQ中的许多语言 struct 已经添加到Oracle的实现中，而原始规范仍然有效，以确保向后兼容.该计划将允许the two platforms个之间的无缝migrations.