"Bernd Helmle" <mailings@oopsware.de>
> Hi folks,
> The supported syntax is
>
> CREATE VIEW foo AS SELECT ... [WITH [LOCAL | CASCADED] CHECK OPTION];
>
> The LOCAL and CASCADED keywords are optional when a CHECK OPTION is
> specified, the default is CASCADED (this syntax creates a shift/reduce
> conflict in the grammar file i don't know how to fix).

Maybe you can fix it like UNIONJOIN. See parser.c.
But Tom said he want to remove the support for UNION JOIN and save the
overhead:
http://archives.postgresql.org/pgsql...3/msg00344.php

Regards,
William ZHANG

On Sun, 2006-03-12 at 23:39 +0800, William ZHANG wrote:
> Maybe you can fix it like UNIONJOIN.

Indeed, that is one option. Because the syntax is WITH [ LOCAL |
CASCADED ] CHECK OPTION, ISTM we'll actually need three new tokens:
WITH_LOCAL, WITH_CASCADED, and WITH_CHECK, which is even uglier :-( Per
a suggestion from Dennis Bjorklund, it might be cleaner to introduce a
lexer hack for the places where WITH can occur in a SelectStmt, which I
believe is just WITH TIME ZONE.

> But Tom said he want to remove the support for UNION JOIN and save the
> overhead

It would be unfortunate to revert the change, but I doubt the overhead
is very significant. Does anyone have any better suggestions for how to
resolve the problem? (My Bison-foo is weak, I have to confess...)

-Neil



---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Neil Conway <neilc@samurai.com> writes:
> On Sun, 2006-03-12 at 23:39 +0800, William ZHANG wrote:
>> Maybe you can fix it like UNIONJOIN.

> Indeed, that is one option.

Not any more ;-)

> It would be unfortunate to revert the change, but I doubt the overhead
> is very significant. Does anyone have any better suggestions for how to
> resolve the problem? (My Bison-foo is weak, I have to confess...)

Worst case is we promote WITH to a fully reserved word. While I don't
normally care for doing that, it *is* a reserved word per SQL99, and
offhand I don't see likely scenarios for someone using "with" as a table
or column or function name. (Anyone know of a language in which "with"
is a noun or verb?)

A quick look at the grammar suggests that the key problem is the
opt_timezone production --- it might be that if we removed that in
favor of spelling out the alternatives at the call sites, the conflict
would go away. bison-fu is all about postponing shift/reduce decisions
until you've seen enough to be sure ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

> A quick look at the grammar suggests that the key problem is the
> opt_timezone production --- it might be that if we removed that in
> favor of spelling out the alternatives at the call sites, the conflict
> would go away. bison-fu is all about postponing shift/reduce decisions
> until you've seen enough to be sure ...
>
> regards, tom lane

Yes, if we can change opt_timezone and related production rules,
it is a better choice.
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Tom Lane wrote:

>Worst case is we promote WITH to a fully reserved word. While I don't
>normally care for doing that, it *is* a reserved word per SQL99, and
>offhand I don't see likely scenarios for someone using "with" as a table
>or column or function name. (Anyone know of a language in which "with"
>is a noun or verb?)
>
>
>

If we eventually support a WITH clause for recursive queries I suspect
we won't have much choice anyway. I could imagine someone using "with"
as a column name, but I can't see how to avoid hurting those people.

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org