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: Andrew Dunstan <andrew(at)dunslane(dot)net>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-patches(at)postgresql(dot)org
Subject: Re: Allow an alias for the target table in UPDATE/DELETE
Date: 2006-01-22 18:59:18
Message-ID: 1137956358.8798.56.camel@localhost.localdomain (view raw or flat)
Thread:
Lists: pgsql-patches
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



In response to

Responses

pgsql-patches by date

Next:From: Tom LaneDate: 2006-01-22 19:20:31
Subject: Re: Allow an alias for the target table in UPDATE/DELETE
Previous:From: Andrew DunstanDate: 2006-01-22 18:51:26
Subject: Re: Allow an alias for the target table in UPDATE/DELETE

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