Re: [HACKERS] check_srf_call_placement() isn't always setting p_hasTargetSRFs

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] check_srf_call_placement() isn't always setting p_hasTargetSRFs
Дата
Msg-id 22696.1484595298@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] check_srf_call_placement() isn't always setting p_hasTargetSRFs  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] check_srf_call_placement() isn't always settingp_hasTargetSRFs  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
I wrote:
> Andres Freund <andres@anarazel.de> writes:
>> I wonder if there should be a seperate expression type for
>> the INSERT ... VALUES(exactly-one-row); since that behaves quite
>> differently.

> Perhaps.  Or maybe we should just use EXPR_KIND_SELECT_TARGET for that?

After looking around, I think we probably better use a different
EXPR_KIND; even if all the functionality is identical, we don't want
ParseExprKindName() to say "SELECT" when we're throwing an error for
INSERT...VALUES.

Also, I noticed that we don't actually allow SRFs in VALUES RTEs:

regression=# select * from (values(1,generate_series(11,13)),(2,0)) v;
ERROR:  set-valued function called in context that cannot accept a set

That's because ValuesNext doesn't handle it.  I'm not particularly
excited about fixing that, given that it's always been that way and
no one has complained yet.  But check_srf_call_placement() is misinformed,
since it thinks the case works.

Will go fix these things.
        regards, tom lane



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: [HACKERS] patch: function xmltable
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Implement targetlist SRFs using ROWS FROM() (wasChanged SRF in targetlist handling)