Thread: Pluggable Parser
<div class="WordSection1"><p class="MsoNormal"><b><u>What is Pluggable Parser</u></b>:<p class="MsoNormal" style="text-indent:36.0pt">Itis an option for users to select a different kind of parser to evaluate PostgreSQL for theirbusiness logic without much manual effort. <p class="MsoNormal"> <p class="MsoNormal"><b><u>Why do we need?</u></b><pclass="MsoNormal" style="margin-left:21.0pt">As of now migration from other databases to PostgreSQL requiresmanual effort of translating SQL & PL/SQL to PostgreSQL equivalent SQL queries. Because of this manual effortin converting scripts, migration to PostgreSQL considered to be very slow and sometime de-motivating also. So ifwe allow to plug different database syntaxes with PostgreSQL, then it will be one of the strong motivating result for manyDBAs to try PostgreSQL.<p class="MsoNormal" style="margin-left:21.0pt"> <p class="MsoNormal"><b><u>How to Do?</u></b><pclass="MsoNormal" style="margin-left:36.0pt">This can be realized by supporting new SQL/Stored procedures syntaxesin 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.<p class="MsoNormal" style="margin-left:36.0pt"> <pclass="MsoNormal" style="margin-left:36.0pt">Parser Interface:<p class="MsoNormal" style="margin-left:21.0pt;text-indent:21.0pt">/*Hook for plugins to get control in Parser */<p class="MsoNormal" style="margin-left:21.0pt;text-indent:21.0pt">typedefList * (*parser_hook_type) const char *str);<p class="MsoNormal" style="margin-left:21.0pt;text-indent:21.0pt">parser_hook_typeparser_hook = NULL;<p class="MsoNormal" style="margin-left:21.0pt;text-indent:21.0pt">externPGDLLIMPORT parser_hook_type parser_hook;<p class="MsoNormal" style="margin-left:21.0pt;text-indent:21.0pt"> <pclass="MsoNormal" style="margin-left:36.0pt">Make the parser entry pointas function pointer (“raw_parser”); which can be loaded based on parser type. The parse_hook will be initialized withproper function during shared library loading, which is done only during server startup. By this way it can be ensuredas only one parser which is provided by the user is used in the PostgreSQL.<p class="MsoNormal"> <pclass="MsoNormal"> Each Database syntax related parser can be implemented as part of contrib module to keepit separate from the core code.<p class="MsoNormal"> <p class="MsoNormal">To start with, I am planning to (For 2015-06commitFest):<p class="MsoListParagraph" style="margin-left:54.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo1"><spanstyle="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman""> </span></span>Support infrastructureto allow plugging.<p class="MsoListParagraph" style="margin-left:54.0pt;text-indent:-18.0pt;mso-list:l0 level1lfo1"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman""> </span></span>Support of ORACLESQL query syntaxes.<p class="MsoListParagraph" style="margin-left:54.0pt"> <p class="MsoNormal">Please let me knowif community will be interested in this or if there were already any discussion about this in past?<p class="MsoNormal"> <pclass="MsoNormal">Please provide your opinion/suggestion. <p class="MsoNormal"> <pclass="MsoNormal"><i><span style="color:black">Thanks and Regards,</span></i><p class="MsoNormal"><i>KumarRajeev Rastogi<span style="color:black"> </span></i></div>
Rajeev rastogi <rajeev.rastogi@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 withoutmuch manual effort. > Why do we need? > As of now migration from other databases to PostgreSQL requires manual effort of translating SQL & PL/SQL to PostgreSQLequivalent SQL queries. Because of this manual effort in converting scripts, migration to PostgreSQL consideredto 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