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

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

Ah, interesting point (I happen to like the terse syntax and use it
often).  This is for posterity anyways since you guys seem to like
Atri's proposal, which surprised me.  However, I think you're over
simplifying things here.  Syntax aside: I think
SELECT f FROM foo f;
and a hypothetical
SELECT row(f.*) FROM foo f;

give different semantics.  The former gives an object of type 'f' and
the latter gives type 'row'.  To get parity, you'd have to add an
extra cast which means you'd have to play tricky games to avoid extra
performance overhead besides being significantly more verbose.  I'm
aware some of the other QUELisms are pretty dodgy and have burned us
in the past (like that whole function as record reference thing) but
pulling a record as a field in select is pretty nice.  It's also
widely used and quite useful in json serialization.

merlin



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

Предыдущее
От: CK Tan
Дата:
Сообщение: Re: Vitesse DB call for testing
Следующее
От: Merlin Moncure
Дата:
Сообщение: Re: Vitesse DB call for testing