Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-01-17T19:15:21Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes: > On 2017-01-17 13:43:38 -0500, Tom Lane wrote: >> I'm not convinced that that optimization is worth preserving, but if we >> keep it then ProjectSet isn't le mot juste here, any more than you'd want >> to rename Result to Project without changing its existing >> functionality. > Right. I'd removed that, and re-added it; primarily because the plans > looked more complex without it. After all, you'd thought it worth adding > that hack ;) I'm happy with removing it again too. Well, it seemed reasonable to do that as long as the only cost was ten or so lines in create_projection_plan. But if we're contorting not only the behavior but the very name of the SRF-evaluation plan node type, that's not negligible cost anymore. So now I'm inclined to take it out. regards, tom lane
Commits
-
Remove obsoleted code relating to targetlist SRF evaluation.
- ea15e18677fc 10.0 landed
-
Doc: improve documentation of new SRF-in-tlist behavior.
- f13a1277aa2d 10.0 landed
-
Move targetlist SRF handling from expression evaluation to new executor node.
- 69f4b9c85f16 10.0 landed
-
Don't split up SRFs when choosing to postpone SELECT output expressions.
- d543170f2fdd 9.6.0 cited