Re: Allow an alias for the target table in UPDATE/DELETE

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Atsushi Ogawa <atsushi(dot)ogawa(at)gmail(dot)com>, pgsql-patches(at)postgresql(dot)org
Subject: Re: Allow an alias for the target table in UPDATE/DELETE
Date: 2006-01-22 07:26:05
Message-ID: 1137914765.8798.38.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Neil Conway 2006-01-22 07:43:31 Re: Allow an alias for the target table in UPDATE/DELETE
Previous Message Tom Lane 2006-01-22 07:23:46 Re: Allow an alias for the target table in UPDATE/DELETE