Re: request for sql3 compliance for the update command

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

In response to

Responses

Browse pgsql-hackers by date

  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