Re: Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Rushabh Lathia <rushabh.lathia@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2017-01-30T23:54:50Z
Lists: 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
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