Re: Allow an alias for the target table in UPDATE/DELETE - Mailing list pgsql-patches

From Neil Conway
Subject Re: Allow an alias for the target table in UPDATE/DELETE
Date
Msg-id 1137914765.8798.38.camel@localhost.localdomain
Whole thread Raw
In response to Re: Allow an alias for the target table in UPDATE/DELETE  (Neil Conway <neilc@samurai.com>)
List pgsql-patches
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



pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: Allow an alias for the target table in UPDATE/DELETE
Next
From: Neil Conway
Date:
Subject: Re: Allow an alias for the target table in UPDATE/DELETE