Re: Parser extensions (maybe for 10?)
| От | Pavel Stehule |
|---|---|
| Тема | Re: Parser extensions (maybe for 10?) |
| Дата | |
| Msg-id | CAFj8pRAYQ_Zg6W5ia1RE7vCcOwT3XdKr0OiRoHCEfq1Vb6sycw@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:44 GMT+02:00 Aleksander Alekseev <a.alekseev@postgrespro.ru>:
> It depends - can be allowed only one - like plpgsql extensions, or
> can be serialized like pg log extensions
OK, I understand "can be allowed only one". I doubt it would be a very
useful feature though.
I'm not sure what do you mean by "serialized like pg log extensions".
Lets say extension A allows "SELECT ASAP ..." queries and extension B
--- "... ORDER BY RANK". What happens when user executes "SELECT
ASAP ... ORDER BY RANK" query?
no - it is not possible. Not with Bison parser - it cannot work with unknown syntax - so isn't possible implement one part by parser A, and second part by parser B.
But we can parsers P1 and P2. P1 knows string XX, P2 knows YY. Buildin parser (BP) knows SQL
We can have registered parsers P1, P2, BP.
for string SELECT
P1 fails,
P2 fails,
BP processes it
for string YY
P1 fails,
P2 process it,
BP is not called
But transformations can be allowed too (but it is slower)
for string ZZZZ
P1 does transformation to YYY
P2 does transformation to SELECT
BP processes it
В списке pgsql-hackers по дате отправления: