From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Dave Cramer <dave(at)fastcrypt(dot)com>, Patrick Welche <prlw1(at)newn(dot)cam(dot)ac(dot)uk>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: request for sql3 compliance for the update command |
Date: | 2003-02-20 04:19:36 |
Message-ID: | 17070.1045714776@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> While I don't see the syntax of:
> update table set (col...) = ( val...)
> as valuable compared to separate col=val assignments, I do see a value
> in allowing subqueries in such assignments:
> update table set (col...) = ( select val ..)
Hm. That's at least got some defensibility to it. But does it do
anything that you can't already do with a join?
BTW, looking at the SQL99 standard, I see that you can do
UPDATE table SET ROW = foo WHERE ...
where foo is supposed to yield a row of the same rowtype as table
--- I didn't dig through the spec in detail, but I imagine foo can
be a sub-select. I don't care a whole lot for that, though, since it
would be a real pain in the neck if you're not updating all the columns.
You'd have to go
UPDATE table SET ROW = (SELECT table.a, table.b, foo.x, ... FROM foo)
which seems ugly, tedious, and error-prone.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Gavin Sherry | 2003-02-20 04:49:16 | Re: request for sql3 compliance for the update command |
Previous Message | Bruce Momjian | 2003-02-20 04:16:17 | Re: request for sql3 compliance for the update command |