From: Tom Lane <tgl@sss.pgh.pa.us>
To: Arcadiy Ivanov <arcadiy@gmail.com>
cc: pgsql-hackers@postgresql.org
Subject: Re: Parser extensions (maybe for 10?)
In-reply-to: <570C7B5A.9070309@gmail.com>
References: <570C7B5A.9070309@gmail.com>
Comments: In-reply-to Arcadiy Ivanov <arcadiy@gmail.com>
	message dated "Tue, 12 Apr 2016 00:36:42 -0400"
Date: Tue, 12 Apr 2016 01:10:31 -0400
Message-ID: <5688.1460437831@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Arcadiy Ivanov <arcadiy@gmail.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.

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers