Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-01-18T21:47:02Z
Lists: pgsql-hackers
Hi, On 2017-01-18 15:24:32 -0500, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > Yea, have something lying around. Let me push it then when I get back from lunch? > > Sure, no sweat. Pushed. Yay! 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: postgres[28758][1]=# SELECT generate_series(1,generate_series(1,5)); ┌─────────────────┐ │ generate_series │ ├─────────────────┤ │ 1 │ │ 1 │ │ 2 │ │ 1 │ │ 2 │ │ 3 │ Am I misunderstanding what you meant? I left it in what I committed, but we probably should clear up the language there. 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. - Andres
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