| 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: | Whole Thread | Raw Message | 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 |