Re: Parser extensions (maybe for 10?)

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: Parser extensions (maybe for 10?)
Дата
Msg-id CAMsr+YGfRw+k4e-GJ+eWsueAjnjGgA0a-Uuo1g8q2_u2p9tYiw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Parser extensions (maybe for 10?)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Parser extensions (maybe for 10?)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 12 April 2016 at 13:10, Tom Lane <tgl@sss.pgh.pa.us> wrote:

I'm interested in possible solutions to this problem, but it's far
harder than it looks.


Exactly.

Limited extension points where we accept runtime errors and confine the extension points can be OK; e.g. SOME STATEMENT ... WITH (THINGY, OTHER_THINGY) where we allow any series of identifier|keyword|literal|bareword, accumulate it and pass it as a List of Node to something else to deal with. Bison can cater to that and similar structures where the boundaries of the generic/extensible region can be clearly defined and limited.

The other area where there's room for extension without throwing out the whole thing and rebuilding is handling of new top-level statements. We can probably dispatch the statement text to a sub-parser provided by an extension that registers interest in that statement name when we attempt to parse it and fail. Even then I'm pretty sure it won't be possible to do so while still allowing multi-statements. I wish we didn't support multi-statements, but we're fairly stuck with them.

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Parser extensions (maybe for 10?)
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: Parser extensions (maybe for 10?)