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

On Sat, Aug 19, 2017 at 4:29 PM, MauMau <maumau307(at)gmail(dot)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(at)postgresql(dot)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