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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)
Дата
Msg-id 11652.1485820490@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f)  (Andres Freund <andres@anarazel.de>)
Ответы Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f)  (Robert Haas <robertmhaas@gmail.com>)
Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f)  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
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.
        regards, tom lane



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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: [HACKERS] Subtle bug in "Simplify tape block format" commit
Следующее
От: David Rowley
Дата:
Сообщение: Re: [HACKERS] Performance improvement for joins where outer side is unique