Peter Eisentraut <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
