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);
neilc=# update t1 set set a = 500 where set.a > 1000;
(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
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.
In response to
pgsql-patches by date
|Next:||From: Tom Lane||Date: 2006-01-22 19:20:31|
|Subject: Re: Allow an alias for the target table in UPDATE/DELETE |
|Previous:||From: Andrew Dunstan||Date: 2006-01-22 18:51:26|
|Subject: Re: Allow an alias for the target table in UPDATE/DELETE|