Re: Parser extensions (maybe for 10?)
От | Aleksander Alekseev |
---|---|
Тема | Re: Parser extensions (maybe for 10?) |
Дата | |
Msg-id | 20160418182523.3f70ad88@fujitsu обсуждение исходный текст |
Ответ на | Re: Parser extensions (maybe for 10?) (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: Parser extensions (maybe for 10?)
|
Список | pgsql-hackers |
> 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? -- Best regards, Aleksander Alekseev http://eax.me/
В списке pgsql-hackers по дате отправления: