On Wed, May 24, 2006 at 01:13:06PM +0200, Peter Eisentraut wrote:
> CREATE VIEW foo AS SELECT expr :: TIME . WITH
>
> (where expr is a_expr or b_expr and TIME could also be TIMESTAMP or TIME(x) or
> TIMESTAMP(x)).
>
> The continuation here could be WITH TIME ZONE (calling for a shift) or WITH
> CHECK OPTION (calling for a reduce).
>
> All the usual ideas about unfolding the rules or making keywords more reserved
> don't work (why should they). A one-token lookahead simply can't parse this.
>
> I have had some ideas about trying to play around with the precedence rules --
> giving WITH TIME ZONE a higher precedence than WITH CHECK OPTION -- but I
> have no experience with that and I am apparently not doing it right, if that
> is supposed to work at all.
All precedence rules do is force the parser to either shift or reduce
without complaining about a conflict. i.e. it resolves the conflict by
forcing a particular option.
So all you would acheive with precedence rules is that you codify the
solution. For example: always shift and if the user specifies WITH
CHECK they get a parse error. It would be nice to be able to detect
this and tell the user to parenthesise the (expr::TIME) thus solving
the problem. Given that :: is not SQL-standard anyway, perhaps this is
not a bad solution.
Incidently, IIRC the default behaviour on conflict is a shift anyway,
so that what the patch already does anyway.
So we get:
CREATE VIEW foo AS SELECT expr :: TIME WITH TIME ZONE <-- OK
CREATE VIEW foo AS SELECT expr :: TIME WITH CHECK OPTION <-- parse error
CREATE VIEW foo AS SELECT (expr :: TIME) WITH CHECK OPTION <-- OK
Of course, any code that decompiles into SQL will have to be careful to
not produce unparseable SQL.
Have a ncie day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.