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: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-01-19T00:08:04Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes: > So, one of the big reasons I use CASE is to avoid evaluating > expressions in cases where they might throw an ERROR. Like, you know: > CASE WHEN d != 0 THEN n / d ELSE NULL END > I guess it's not the end of the world if that only works for > non-set-returning functions, but it's something to think about. Well, refusing CASE-containing-SRF at all isn't going to make your life any better in that regard :-( It's possibly worth noting that this is also true for aggregates and window functions: wrapping those in a CASE doesn't stop them from being evaluated, either. People seem to be generally used to that, although I think I've seen one or two complaints about it from folks who seemed unclear on the concept of aggregates. In the end I think this is mostly about backwards compatibility: are we sufficiently worried about that that we'd rather throw an error than have a silent change of behavior? TBH I'm not sure. We've certainly got two other silent changes of behavior in this same patch. The argument for treating this one differently, I think, is that it's changing from a less surprising behavior to a more surprising one whereas the other changes are the reverse, or at worst neutral. 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