I just came across the following paper and project and thought I would

It seems some incremental graph query extensions to SQL could add some
powerful capabilities to PostgreSQL (without having to think about a
complete query language replacement). The incremental change could include:
paths as first class citizens and a new MATCH keyword.

This is what I was reading:

https://arxiv.org/abs/1712.01550*  G-CORE A Core for Future Graph Query
Languages *

*"Path as first-class citizens. The notion of Path is fundamental for graph
databases, because it introduces an intermediate abstraction level that
allows to represents how elements in a graph are related. The facilities
provided by a graph query language to manipulate paths (i.e. describe,
search, filter, count, annotate, return, etc.) increase the expressivity of
the language. Particularly, the ability to return paths enables the user to
post-process paths within the query language rather that in an ad-hoc
manner [15]." *

They have an open source parser for G-Core here:

"This is a G-Core query example which matches persons with the name “John
Doe” together with indirect friends that live in the same city and returns
a table with the names of these friends."

SELECT m.lastName + ', ' + m.firstName AS friendName MATCH (n:Person)-/<:

WHERE n.firstName = 'John' AND n.lastName = 'Doe' AND (n)-[:isLocatedIn

Oracle has a similar graph query language as well: http://pgql-lang.org

SELECT p2.name AS friend_of_friend
  FROM facebook_graph                             /* In the Facebook
graph..   */
 MATCH (p1:Person) -/:friend_of{2}/-> (p2:Person) /* ..match two-hop
friends.. */
 WHERE p1.name = 'Mark'                           /* ..of Mark.

And Microsoft SQL server added limited MATCH capability:


On Sun, Dec 3, 2017 at 2:37 PM Deep-Impact <sakasaumau2...@clear.ocn.ne.jp>

> From: Tom Lane
> It sounds like what you want is to replace all of Postgres except
> the name.  I'm not clear on the point.
> The point is to make PostgreSQL a versatile database suitable even for
> niche use cases.  I want more people to love and rely on PostgreSQL.
> Ideally, I want to see various data models incorporated in core from
> the beginning, but it would be difficult.  So, this pluggable data
> model is necessary to foster data model development both inside and
> outside the PostgreSQL community.  With that said, I hope PostgreSQL
> will someday absorb those data models, just like PL/pgSQL is now in
> core.
> But for now, I think the relational data model will continue to play a
> central role.  I don't think it's worth making the current relational
> data model implementation a plugged module.  It will depend on the
> software design and source code cleanness whether to do that.
> I don't understand yet how painful it would be to support other data
> models as first-class citizens, and I may be a reckless man who
> doesn't know fear.  So I wish you could help and pave this difficult
> way together.
> Regards
> MauMau

Reply via email to