Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers