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>
Subject: Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in
 targetlist handling)
In-reply-to: 
 <CA+TgmoYDBRProZ4ixWpi23No9oWdO=NQZcKzQGbk4Liioe35mw@mail.gmail.com>
References: <12780.1484747004@sss.pgh.pa.us>
 <20170118191924.25lfp6rd6y3kw5sa@alap3.anarazel.de>
 <13690.1484767452@sss.pgh.pa.us>
 <20170118193420.znochutmnzusd636@alap3.anarazel.de>
 <15814.1484769612@sss.pgh.pa.us>
 <460325A6-EF35-4A29-A1A0-EEDC3EDCF750@anarazel.de>
 <22709.1484771072@sss.pgh.pa.us>
 <20170118214702.54b2mdbxce5piwv5@alap3.anarazel.de>
 <1080.1484776606@sss.pgh.pa.us> <15818.1484781266@sss.pgh.pa.us>
 <20170118231945.27ivk7cjaq23y6r3@alap3.anarazel.de>
 <CA+TgmoYDBRProZ4ixWpi23No9oWdO=NQZcKzQGbk4Liioe35mw@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Wed, 18 Jan 2017 18:59:00 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <17805.1484784484.1@sss.pgh.pa.us>
Date: Wed, 18 Jan 2017 19:08:04 -0500
Message-ID: <17806.1484784484@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers