On Sun, 2006-01-22 at 02:05 -0500, Neil Conway wrote: > I believe the conflict results from the fact that ColId can include SET > (since it is an unreserved_keyword), but SET might also be the next > token in the UpdateStmt, and yacc is not capable of distinguishing > between these two cases. We could fix this by promoting SET to be a > func_name_keyword or reserved_keyword, but that seems unfortunate.
On thinking about this a bit more, an alternative fix would be to make AS mandatory. That is unappealing because the SQL spec requires that it be optional, as well as for consistency with aliases in SELECT's FROM list. Another possibility is to disallow SET here, but not in other places where ColId is used. That is, some hack like: ColId_no_set: IDENT | unreserved_keyword | col_name_keyword ; ColId: ColId_no_set | SET ; relation_expr_opt_alias: relation_expr | relation_expr opt_as ColId_no_set ... along the corresponding changes to the other productions that deal with keywords (removing SET from unreserved_keywords and adding it manually as an alternative to type_name, function_name, etc.). Needless to say, that is also very ugly. -Neil ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org