From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | 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:19:55 |
Message-ID: | CAFj8pRA6hAG3kg+iANEad+7b+u_Y-Pqnaz-q0TbwBX4h=5h_Yw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi
2016-04-12 7:10 GMT+02:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Arcadiy Ivanov <arcadiy(at)gmail(dot)com> writes:
> > Is there any interest and/or tips to allow a pluggable parser or at
> > least allow some syntactical pluggability by extensions?
>
> There is a fair amount of discussion of this in the archives. The short
> answer is that bison can't do it, and "let's replace bison" is a proposal
> with a steep hill in front of it --- the pain-to-gain ratio is just not
> very favorable.
>
> Forty years ago, I worked on systems with extensible parsers at HP,
> wherein plug-in extensions could add clauses very similarly to what
> you suggest. Those designs worked, more or less, but they had a lot
> of deficiencies; the most fundamental problem being that any parsing
> inconsistencies would only appear through misbehavior at runtime,
> which you would only discover if you happened to test a case that behaved
> oddly *and* notice that it was not giving the result you expected.
> Bison is far from perfect on this angle, because %prec declarations can
> produce results you weren't expecting ... but it's at least one order of
> magnitude better than any extensible-parser solution I've ever seen.
> Usually bison will give you a shift/reduce error if you write something
> that has more than one possible interpretation.
>
> I'm interested in possible solutions to this problem, but it's far
> harder than it looks.
>
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?
Regards
Pavel
>
> regards, tom lane
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-04-18 15:24:07 | Re: Spinlocks and semaphores in 9.2 and 9.3 |
Previous Message | Tom Lane | 2016-04-18 15:18:53 | Re: Should we remove unused code? |