Skip site navigation (1) Skip section navigation (2)

Re: Updatable views/with check option parsing

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: "Andrew Dunstan" <andrew(at)dunslane(dot)net>, kleptog(at)svana(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Updatable views/with check option parsing
Date: 2006-05-27 00:14:00
Message-ID: 3010.1148688840@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: James William PyeDate: 2006-05-27 02:41:46
Subject: pg_proc probin misuse
Previous:From: Peter EisentrautDate: 2006-05-26 23:59:29
Subject: Re: Updatable views/with check option parsing

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group