Re: Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Rushabh Lathia <rushabh.lathia@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2017-03-10T19:49:46Z
Lists: 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
Commits
-
Provide an error cursor for "can't call an SRF here" errors.
- e240a65c7dfc 10.0 landed
-
Pass the source text for a parallel query to the workers.
- 4c728f382970 10.0 cited
-
Move targetlist SRF handling from expression evaluation to new executor node.
- 69f4b9c85f16 10.0 cited