From: Chris Travers > Why cannot you do all this in a language handler and treat as a user defined function? > ... > 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?
The language handler is for *stored* functions. The user-defined function (UDF) doesn't participate in the planning of the outer (top-level) query. And they both assume that they are executed in SQL commands. I want the data models to meet these: 1) The query language can be used as a top-level session language. For example, if an app specifies "region=cypher_graph" at database connection, it can use the database as a graph database and submit Cypher queries without embedding them in SQL. 2) When a query contains multiple query fragments of different data models, all those fragments are parsed and planned before execution. The planner comes up with the best plan, crossing the data model boundary. To take the query example in my first mail, which joins a relational table and the result of a graph query. The relational planner considers how to scan the table, the graph planner considers how to search the graph, and the relational planner considers how to join the two fragments. So in_region() and cast_region() are not functions to be executed during execution phase, but are syntax constructs that are converted, during analysis phase, into calls to another region's parser/analyzer and an inter-model cast routine. 1. The relational parser finds in_region('cypher_graph', 'graph query') and produces a parse node InRegion(region_name, query) in the parse tree. 2. The relational analyzer looks up the system catalog to checks if the specified region exists, then calls its parser/analyzer to produce the query tree for the graph query fragment. The relational analyzer attaches the graph query tree to the InRegion node. 3. When the relational planner finds the graph query tree, it passes the graph query tree to the graph planner to produce the graph execution plan. 4. The relational planner produces a join plan node, based on the costs/statistics of the relational table scan and graph query. The graph execution plan is attached to the join plan node. The parse/query/plan nodes have a label to denote a region, so that appropriate region's routines can be called. 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