Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f)

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f)
Дата
Msg-id CA+TgmobpvpfvN6QvFSM6KMGS=miecxk1mpTTqAdhkmfxrME2+g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f)  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Mon, Jan 30, 2017 at 6:54 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andres Freund <andres@anarazel.de> writes:
>> Wonder if we there's an argument to be made for implementing this
>> roughly similarly to split_pathtarget_at_srf - instead of injecting a
>> ProjectSet node we'd add a FunctionScan node below a Result node.
>
> Yeah, possibly.  That would have the advantage of avoiding an ExecProject
> step when the SRFs aren't buried, which would certainly be the expected
> case.
>
> If you don't want to make ExecInitExpr responsible, then the planner would
> have to do something like split_pathtarget_at_srf anyway to decompose the
> expressions, no matter which executor representation we use.

Did we do anything about this?  Are we going to?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS] PATCH: psql show index with type info
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: [HACKERS] PATCH: psql show index with type info