[HACKERS] Pluggable Parser

[Rajeev rastogi]

What is Pluggable Parser:
It is an option for users to select a different kind of parser to evaluate 
PostgreSQL for their business logic without much manual effort.

Why do we need?
As of now migration from other databases to PostgreSQL requires manual effort 
of translating SQL  PL/SQL to PostgreSQL equivalent SQL queries. Because of 
this manual effort in converting scripts, migration to PostgreSQL considered to 
be very slow and sometime  de-motivating also.  So if we allow to plug 
different database syntaxes with PostgreSQL, then it will be one of the strong 
motivating result for many DBAs to try PostgreSQL.

How to Do?
This can be realized by supporting new SQL/Stored procedures syntaxes in the 
parser corresponding to each other database syntax and plug the one needs to be 
evaluated by putting the corresponding so file in dynamic_library_path. 
Default will be PostgreSQL syntax.

Parser Interface:
/* Hook for plugins to get control in Parser */
typedef List * (*parser_hook_type) const char *str);
parser_hook_type parser_hook = NULL;
extern PGDLLIMPORT parser_hook_type parser_hook;

Make the parser entry point as function pointer (raw_parser); which can be 
loaded based on parser type. The parse_hook will be initialized with proper 
function during shared library loading, which is done only during server 
startup. By this way it can be ensured as only one parser which is provided by 
the user is used in the PostgreSQL.

Each Database syntax related parser can be implemented as part 
of contrib module to keep it separate from the core code.

To start with, I am planning to (For 2015-06 commitFest):

1.   Support infrastructure to allow plugging.

2.   Support of ORACLE SQL query syntaxes.


Please let me know if community will be interested in this or if there were 
already any discussion about this in past?

Please provide your opinion/suggestion.

Thanks and Regards,
Kumar Rajeev Rastogi

Re: [HACKERS] Pluggable Parser

[Tom Lane]

Rajeev rastogi rajeev.rast...@huawei.com writes:
 What is Pluggable Parser:
 It is an option for users to select a different kind of parser to evaluate 
 PostgreSQL for their business logic without much manual effort.

 Why do we need?
 As of now migration from other databases to PostgreSQL requires manual effort 
 of translating SQL  PL/SQL to PostgreSQL equivalent SQL queries. Because of 
 this manual effort in converting scripts, migration to PostgreSQL considered 
 to be very slow and sometime  de-motivating also.  So if we allow to plug 
 different database syntaxes with PostgreSQL, then it will be one of the 
 strong motivating result for many DBAs to try PostgreSQL.

While I don't have any strong reason to object to putting a hook where you
suggest, I think that the above represents an enormous oversale of the
benefits, which in actual fact are likely to be near zero.  Replacing
gram.y as you suggest will not allow more than the most trivial, cosmetic
grammar changes, because you'd still have to produce the same raw parse
trees as before.

Alternatively you could consider replacing both raw_parser() and
parse_analyze(), but then you're talking about maintaining a duplicate
copy of just about the whole of src/backend/parser/, which doesn't sound
terribly practical; it certainly would be unpleasant to maintain such a
thing across multiple PG releases.  And there will still be pretty strong
constraints on whether you could implement say a MySQL-workalike, because
you're still having to work with the Postgres execution engine.

In short, this proposal sounds a lot like a solution looking for a
problem.  I think it would be useful for you to pick a small number of
concrete alternative-grammar problems and think about how you could
provide hooks that would allow solving those issues without duplicating
90% of src/backend/parser/ first.

Here is an example of such a concrete problem: Oracle, I believe, uses
parentheses () rather than brackets [] for array subscripting expressions.
How would you allow that notation in Postgres?  Your original proposal
cannot do it because it's not a problem of the raw grammar, but rather
one for parse analysis --- you have to disambiguate array references
from function calls at the time of doing semantic analysis.

Another example you might consider is Oracle-style outer join notation,
which again will require significant surgery in parse analysis, not
just modifying the raw grammar.

regards, tom lane


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