Re: Allow an alias for the target table in UPDATE/DELETE
От | Neil Conway |
---|---|
Тема | Re: Allow an alias for the target table in UPDATE/DELETE |
Дата | |
Msg-id | 1137956358.8798.56.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: Allow an alias for the target table in UPDATE/DELETE (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Allow an alias for the target table in UPDATE/DELETE
Re: Allow an alias for the target table in UPDATE/DELETE |
Список | 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
В списке pgsql-patches по дате отправления: