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: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Rushabh Lathia <rushabh.lathia@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2017-01-30T23:47:49Z
Lists: pgsql-hackers
On 2017-01-30 17:24:31 -0500, Tom Lane wrote: > Make it work like Agg and WindowFunc. To wit, dump the actually special > function calls (the set-returning functions) into a list that's internal > to the FunctionScan node, and then anything above those goes into scalar > expressions in the node's tlist, which refer to the SRF outputs using > Vars or things morally equivalent to Vars. Hm. That should be fairly doable. (I'd advocate very strongly against building that list via ExecInitExpr, but that's an implementation detail). We'd evaluate SRFs early, but that's just consistent with targetlist SRFs. 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. - 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