Re: Parser extensions (maybe for 10?)
От | Pavel Stehule |
---|---|
Тема | Re: Parser extensions (maybe for 10?) |
Дата | |
Msg-id | CAFj8pRCgwN1drV0V7EWQC8eacYbF091nGpG7BGpQFaFG1mY1xg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Parser extensions (maybe for 10?) (Aleksander Alekseev <a.alekseev@postgrespro.ru>) |
Ответы |
Re: Parser extensions (maybe for 10?)
|
Список | pgsql-hackers |
2016-04-18 17:25 GMT+02:00 Aleksander Alekseev <a.alekseev@postgrespro.ru>:
> I cannot to imagine extensible parser based on bison. But the parser
> can be replaced by custom parser.
>
> Some like pgpool or pgbouncer does. The extension can assign own
> parser. Custom parser will be called first, and the integrated parser
> will be used from extension or as fallback. This can helps with new
> statements for background workers, theoretically it can helps with
> extending PostgreSQL SQL. Custom parser can do translation from SQL1
> to SQL2 dialect, or can do translation from SQL1 to internal calls.
> The custom parser usually should not implement full SQL - only few
> statements.
>
> Is it this idea more workable?
What if there are two or more contribs that extend the parser? Can we
be sure that these contribs will not conflict?
It depends - can be allowed only one - like plpgsql extensions, or can be serialized like pg log extensions
Regards
Pavel
--
Best regards,
Aleksander Alekseev
http://eax.me/
В списке pgsql-hackers по дате отправления: