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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
