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

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Support UPDATE table SET(*)=...
Дата
Msg-id CAB7nPqTR+LJrKYo4X-S28+zc5Hxp=PSvrbCsR1FbFrQdmS_Jng@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Support UPDATE table SET(*)=...  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Support UPDATE table SET(*)=...  (Atri Sharma <atri.jiit@gmail.com>)
Список pgsql-hackers
On Wed, Nov 26, 2014 at 4:26 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I think what's likely missing here is a clear design for the raw parse
> tree representation (what's returned by the bison grammar).  The patch
> seems to be trying to skate by without creating any new parse node types
> or fields, but that may well be a bad idea.  At the very least there
> needs to be some commentary added to parsenodes.h explaining what the
> representation actually is (cf commentary there for MultiAssignRef).
>
> Also, I think it's a mistake not to be following the MultiAssignRef
> model for the case of "(*) = ctext_row".  We optimize the ROW-source
> case at the grammar stage when there's a fixed number of target columns,
> because that's a very easy transformation --- but you can't do it like
> that when there's not.  It's possible that that optimization should be
> delayed till later even in the existing case; in general, optimizing
> in gram.y is a bad habit that's better avoided ...
Marking as "returned with feedback" based on those comments.
-- 
Michael



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Selectivity estimation for inet operators
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: 9.5: Better memory accounting, towards memory-bounded HashAgg