Re: [PATCHES] extension for sql update - Mailing list pgsql-hackers

From Rod Taylor
Subject Re: [PATCHES] extension for sql update
Date
Msg-id 1154306310.24186.236.camel@home
Whole thread Raw
In response to Re: [PATCHES] extension for sql update  (Robert Treat <xzilla@users.sourceforge.net>)
Responses Re: [PATCHES] extension for sql update
List pgsql-hackers
On Sun, 2006-07-30 at 20:20 -0400, Robert Treat wrote:
> On Thursday 27 July 2006 09:28, Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Bruce Momjian <bruce@momjian.us> writes:
> > > > Tom Lane wrote:
> > > >> UPDATE mytab SET (foo, bar, baz) =
> > > >> (SELECT alpha, beta, gamma FROM othertab WHERE key = mytab.key);
> > > >
> > > > That UPDATE example is interesting because I remember when using
> > > > Informix that I had to do a separate SELECT statement for each UPDATE
> > > > column I wanted to update.  I didn't realize that you could group
> > > > columns and assign them from a single select --- clearly that is a
> > > > powerful syntax we should support some day.
> > >
> > > No question.  The decision at hand is whether we want to look like
> > > we support it, when we don't yet.  I'd vote not, because I think the
> > > main use-case for the row-on-the-left syntax is exactly this, and
> > > so I fear people will just get frustrated if they see it in the
> > > syntax synopsis and try to use it.
> >
>
> I'm not a big fan of implementing partial solutions (remember "left-joins are
> not implemented messages" :-) way back when) , however in my experience with
> this form of the update command, the primary usage is not to use a subselect
> to derive the values, but to make it easier to generate sql, using a single

I disagree. UPDATE mytab SET (foo, bar, baz) =(SELECT ...) is the
specifications way of doing an update with a join. That is its primary
purpose.

UPDATE ... FROM  is a PostgreSQL alternative to the above.
--


pgsql-hackers by date:

Previous
From: Robert Treat
Date:
Subject: Re: [PATCHES] extension for sql update
Next
From: Robert Treat
Date:
Subject: Re: 64-bit integers for GUC