Re: [HACKERS] [RFC] What would be difficult to make data modelspluggable for making PostgreSQL a multi-model database?

Поиск
Список
Период
Сортировка
От Chris Travers
Тема Re: [HACKERS] [RFC] What would be difficult to make data modelspluggable for making PostgreSQL a multi-model database?
Дата
Msg-id CAN-RpxBYy4DJdTwszP3JbQ2wacBpbwjYeQrqUfo2cFn2=UvSQw@mail.gmail.com
обсуждение исходный текст
Ответ на [HACKERS] [RFC] What would be difficult to make data models pluggable for making PostgreSQL a multi-model database?  ("MauMau" <maumau307@gmail.com>)
Ответы Re: [HACKERS] [RFC] What would be difficult to make data models pluggable for making PostgreSQL a multi-model database?  ("MauMau" <maumau307@gmail.com>)
Список pgsql-hackers


On Sat, Aug 19, 2017 at 4:29 PM, MauMau <maumau307@gmail.com> wrote:
Hello,

Please forgive me for asking such a stupid and rough question.

I'm thinking of making PostgreSQL a multi-model database by supporting
data models other than the current relational model.  A data model
consists of a query language (e.g. SQL for relational model, Cypher
for graph model), a parser and analyzer to transform a query into a
query tree, a planner to transform the query tree into an execution
plan, an executor, and a storage engine.

To promote the data model development, I want to make data models
pluggable.  The rough sketch is:

1) A data model developer implements the parser, analyzer,
transformer, planner, executor, and storage engine functions in a
shared library.

2) The DBA registers the data model.

  CREATE QUERY LANGUAGE Cypher (
    PARSER = <parser function>
  );

  CREATE DATA MODEL graph (
    QUERY LANGUAGE = Cypher,
    ANALYZER = <analyzer function>,
    TRANSFORMER = <transformer function>,
    PLANNER = <planner function>,
    EXECUTOR = <executor function>,
    STORAGE ENGINE = <storage engine function>,
  );

  CREATE REGION cypher_graph (
    QUERY LANGUAGE = Cypher,
    DATA MODEL = graph
  );

Why cannot you do all this in a language handler and treat as a user defined function? 

The region is just a combination of a query language and a data model,
much like a locale is a combination of a language and a country.  This
is because there may be multiple popular query languages for a data
model.

3) The application connects to the database, specifying a desired
region.  The specified region's query language becomes the default
query language for the session.


The application can use the data of multiple data models in one query
by specifying another region and its query via in_region().  For
example, the following query combines the relational restaurant table
and a social graph to get the five chinese restaurants in Tokyo that
are most popular among friends of John and their friends.

  SELECT r.name, g.num_likers
  FROM restaurant r,
    cast_region(
      in_region('cypher_graph',
        'MATCH (:Person {name:"John"})-[:IS_FRIEND_OF*1..2]-(friend),
          (friend)-[:LIKES]->(restaurant:Restaurant)
          RETURN restaurant.name, count(*)'),
    'relational', 'g', '(name text, num_likers int')
  WHERE r.name = g.name AND
    r.city = 'Tokyo' AND r.cuisine = 'chinese'
  ORDER BY g.num_likers DESC LIMIT 5

If you have a language handler for cypher, why do you need in_region or cast_region?  Why not just have a graph_search() function which takes in a cypher query and returns a set of records?
;


What do you think would be difficult to make data models pluggable,
especially related to plugging the parser, planner, executor, etc?
One possible concern is that various PostgreSQL components might be
too dependent on the data model being relational, and it would be
difficult to separate tight coupling.

I guess I am missing why the current language handler structure is not enough.  Maybe I am missing something?
 

Regards
MauMau



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



--
Best Regards,
Chris Travers
Database Administrator

Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com 
Saarbrücker Straße 37a, 10405 Berlin

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

Предыдущее
От: "MauMau"
Дата:
Сообщение: [HACKERS] [RFC] What would be difficult to make data models pluggable for making PostgreSQL a multi-model database?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] [RFC] What would be difficult to make data models pluggable for making PostgreSQL a multi-model database?