Re: Support UPDATE table SET(*)=...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Marko Tiikkaja <marko(at)joh(dot)to>, Atri Sharma <atri(dot)jiit(at)gmail(dot)com>, Marti Raudsepp <marti(at)juffo(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Support UPDATE table SET(*)=...
Date: 2014-10-17 15:30:51
Message-ID: 11801.1413559851@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
> On Fri, Oct 17, 2014 at 10:16 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I think it wouldn't; Merlin is proposing that f would be taken as the
>> field name. A more realistic objection goes like this:
>>
>> create table foo(f int, g int);
>> update foo x set x = (1,2); -- works
>> alter table foo add column x int;
>> update foo x set x = (1,2,3); -- no longer works
>>
>> It's not a real good thing if a column addition or renaming can
>> so fundamentally change the nature of a query.

> That's exactly how SELECT works. I also dispute that the user should
> be surprised in such cases.

Well, the reason we have a problem in SELECT is that we support an
unholy miscegenation of SQL-spec and PostQUEL syntax: the idea that
"SELECT foo FROM foo" could represent a whole-row selection is nowhere
to be found in the SQL standard, for good reason IMO. But we've never
had the courage to break cleanly with this Berkeley leftover and
insist that people spell it SQL-style as "SELECT ROW(foo.*) FROM foo".
I'd just as soon not introduce the same kind of ambiguity into UPDATE
if we have a reasonable alternative.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message CK Tan 2014-10-17 15:47:14 Re: Vitesse DB call for testing
Previous Message Kevin Grittner 2014-10-17 15:23:32 Re: Trailing comma support in SELECT statements