Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)
David G. Johnston <david.g.johnston@gmail.com>
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-01-18T23:27:53Z
Lists: pgsql-hackers
On Wed, Jan 18, 2017 at 4:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I wrote: > > 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. > > Here's what I came up with: > > This behavior also means that set-returning functions will be evaluated > even when it might appear that they should be skipped because of a > conditional-evaluation construct, such as CASE or COALESCE. For example, > consider > > SELECT x, CASE WHEN x > 0 THEN generate_series(1, 5) ELSE 0 END FROM tab; > > It might seem that this should produce five repetitions of input rows > that have x > 0, and a single repetition of those that do not; but > actually it will produce five repetitions of every input row. > > So is this too ugly to live, or shall we put up with it? > > Disallowing such an unlikely, and un-intuitive, corner-case strikes my sensibilities. I'd rather fail now and allow for the possibility of future implementation of the "it might seem that..." behavior. David J.
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