On Sat, Aug 19, 2017 at 4:29 PM, MauMau <maumau...@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