Re: Updatable views/with check option parsing - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Updatable views/with check option parsing
Date
Msg-id 1148717144.4727.5.camel@localhost.localdomain
Whole thread Raw
In response to Re: Updatable views/with check option parsing  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Updatable views/with check option parsing
List pgsql-hackers
Ühel kenal päeval, R, 2006-05-26 kell 22:50, kirjutas Tom Lane:
> I wrote:
> > 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.)
> 
> On investigation that turns out to have been a bad idea: if we do it
> that way, it becomes necessary to promote WITH to a fully reserved word.
> The counterexample is
> 
>     CREATE VIEW v AS SELECT * FROM foo WITH ...
> 
> Is WITH an alias for foo (with no AS), or is it the start of a WITH
> CHECK OPTION?  No way to tell without lookahead.
> 
> While I don't think that making WITH a fully reserved word would cause
> any great damage, I'm unwilling to do it just to save a couple of lines
> of code. 

I think we should go on and do promote WITH to a reserved keyword now
because eventually we have to do it anyway.

It is needed for recursive queries as well. I don't pretend to be an
expert bison coder, but I was unable to define a grammar for
SQL-standard recursive queries without making WITH a reserved keyword.

-- 
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me:  callto:hkrosing
Get Skype for free:  http://www.skype.com




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_proc probin misuse
Next
From: "Marko Kreen"
Date:
Subject: Re: Inefficient bytea escaping?