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-18T21:56:46Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes: > There's one sgml comment you'd added: > "Furthermore, nested set-returning functions did not work at all." > I'm not quite sure what you're referring to there - it was previously > allowed to have one set argument to an SRF: Ooops ... that was composed too hastily, evidently. Will fix. I'll try to write something about the SRF-in-CASE issue too. Seeing whether we can document that adequately seems like an important part of making the decision about whether we need to block it. > Working on rebasing the cleanup patch now. Interested in reviewing > that? Otherwise I think I'll just push the rebased version of what I'd > posted before, after making another pass through it. I have not actually looked at 0003 at all yet. So yeah, please post for review after you're done rebasing. 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