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

On Sun, 2006-01-22 at 13:26 -0500, Tom Lane wrote:
> The effect of this, as Andrew says, is that in this particular context
> you can't write SET as an alias unless you write AS first.

Did you actually test this?

neilc=# create table t1 (a int, b int);
CREATE TABLE
neilc=# update t1 set set a = 500 where set.a > 1000;
UPDATE 0

(Using essentially the patch you posted.)

> This is
> probably not going to surprise anyone in the UPDATE case, since the
> ambiguity inherent in writing
>     UPDATE foo set SET ...
> is pretty obvious.  However it might surprise someone in the DELETE
> context.

Well, if necessary we can just use an alternate production for the
DELETE case, as there is no SET ambiguity to worry about.

> The third alternative is to stop allowing SET as an unreserved_keyword.
> I found that moving it up to func_name_keyword was enough to get rid
> of the conflict, without using precedence.

I think we should avoid this if possible: it seems quite likely to me
that there are applications using SET as the name of a type, table or
column (making SET a func_name_keyword would disallow its use as a type
name, AFAICS). So I'm inclined to favor #2.

-Neil