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.
signature.asc
Description: Digital signature
