Re: [RFC] What would be difficult to make data models pluggable formaking PostgreSQL a multi-model database?

Поиск
Список
Период
Сортировка
От Henry
Тема Re: [RFC] What would be difficult to make data models pluggable formaking PostgreSQL a multi-model database?
Дата
Msg-id CAJVHagthPotwLgUm9wXhNSPCQC6JSmh0uAh+M4o_oabAP9Stgw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [RFC] What would be difficult to make data models pluggable for making PostgreSQL a multi-model database?  ("Deep-Impact" <sakasaumau2009@clear.ocn.ne.jp>)
Список pgsql-hackers
Дерево обсуждения

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 <sakasaumau2009@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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Mark Dilger
Дата:
Сообщение: Re: [HACKERS] PATCH: multivariate histograms and MCV lists
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: [PROPOSAL] timestamp informations to pg_stat_statements