Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group