Re: Changed SRF in targetlist handling
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
Merlin Moncure <mmoncure@gmail.com>, David Fetter <david@fetter.org>, Andres Freund <andres@anarazel.de>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2016-06-06T21:03:29Z
Lists: pgsql-hackers
On Mon, Jun 6, 2016 at 3:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> ... I guess I'd prefer #2 to #2.5, #2.5 to #3, and #3 to #1. >> I really don't like #1 much - I think I'd almost rather do nothing. > > FWIW, that's about my evaluation of the alternatives as well. I fear > that #1 would get a lot of pushback. If we think that something like > "LATERAL ROWS FROM STRICT" is worth having on its own merits, then > doing #2.5 seems worthwhile to me, but otherwise I'm just as happy > with #2. David J. seems to feel that throwing an error (as in #2.5) > rather than silently behaving incompatibly (as in #2) is important, > but I'm not convinced. In a green field I think we'd prefer #2 over > #2.5, so I'd rather go that direction. Same here. That behavior is actually potentially quite useful, right? Like, you might want to rely on the NULL-extension thing, if it were documented as behavior you can count on? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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