Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane wrote:
>> Yeah, I just read the same in the bison manual. The thing that's
>> bothering me is that a GLR parser would hide that ambiguity from you,
> It doesn't really hide it. You still get the "N shift/reduce conflicts"
> warnings from bison. You just know that they are being handled.
Well, that has the same problem that we've raised every other time
someone has said "I don't want to fix the grammar to not have any
conflicts". If bison only tells you "there were N conflicts",
how do you know these are the same N conflicts you had yesterday?
In a grammar that we hack around as much as we do with Postgres,
I really don't think that's acceptable.
I think that by far the most reliable solution is to put back the
"filter" yylex function that I removed a couple months ago:
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/parser/parser.c.diff?r1=1.64&r2=1.65
We can use the same technique that we used for UNION JOIN, but instead
join, say, WITH and TIME into one token and make the time datatype
productions look for "TIME WITHTIME ZONE" and so on. (I propose this
rather than putting the ugliness into WITH CHECK OPTION, because this
way we should only need one merged token and thus only one case to
check in the filter function; AFAICS we'd need three cases if we
merge tokens on that end of it.)
I'm not sure we can just revert the above-mentioned patch, because it
had some interactions with a later patch to use %option prefix.
Shouldn't be too hard to fix though. I'll put together a proposed
patch.
regards, tom lane