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

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f)
Дата
Msg-id 20170310194946.45yvbvuqz3f7b7ru@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f)  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Query fails when SRFs are part of FROM clause (Commit id:69f4b9c85f)  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
On 2017-03-09 13:34:22 -0500, Robert Haas wrote:
> 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?

Working on a patch.

- Andres



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Need a builtin way to run all tests faster manner
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: [HACKERS] Need a builtin way to run all tests faster manner