From: | Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Pluggable Parser |
Date: | 2015-03-27 09:44:04 |
Message-ID: | BF2827DCCE55594C8D7A8F7FFD3AB77159878C2A@szxeml521-mbs.china.huawei.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Vladimir Borodin | 2015-03-27 10:15:34 | Vacuuming big btree indexes without pages with deleted items |
Previous Message | Haribabu Kommi | 2015-03-27 08:23:57 | Re: Providing catalog view to pg_hba.conf file - Patch submission |