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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Support UPDATE table SET(*)=...
Дата
Msg-id 11801.1413559851@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Support UPDATE table SET(*)=...  (Merlin Moncure <mmoncure@gmail.com>)
Ответы Re: Support UPDATE table SET(*)=...
Список pgsql-hackers
Merlin Moncure <mmoncure@gmail.com> writes:
> On Fri, Oct 17, 2014 at 10:16 AM, Tom Lane <tgl@sss.pgh.pa.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kevin Grittner
Дата:
Сообщение: Re: Trailing comma support in SELECT statements
Следующее
От: CK Tan
Дата:
Сообщение: Re: Vitesse DB call for testing