Re: Parser extensions (maybe for 10?)

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Arcadiy Ivanov <arcadiy(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parser extensions (maybe for 10?)
Date: 2016-04-18 15:57:09
Message-ID: CAFj8pRAYQ_Zg6W5ia1RE7vCcOwT3XdKr0OiRoHCEfq1Vb6sycw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2016-04-18 17:44 GMT+02:00 Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)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

--
> Best regards,
> Aleksander Alekseev
> http://eax.me/
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2016-04-18 16:13:40 Re: snapshot too old, configured by time
Previous Message Robert Haas 2016-04-18 15:54:27 Re: Spinlocks and semaphores in 9.2 and 9.3