I just came across the following paper and project and thought I would share:
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: https://github.com/ldbc/ldbc_gcore_parser "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)-/<: knows*>/->(m:Person) WHERE n.firstName = 'John' AND n.lastName = 'Doe' AND (n)-[:isLocatedIn ]->()<-[:isLocatedIn]-(m) 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: https://docs.microsoft.com/en-us/sql/t-sql/queries/match-sql-graph On Sun, Dec 3, 2017 at 2:37 PM Deep-Impact <sakasaumau2...@clear.ocn.ne.jp> wrote: > 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 > > >
