From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling) |
Date: | 2017-01-19 00:08:04 |
Message-ID: | 17806.1484784484@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Petr Jelinek | 2017-01-19 00:18:49 | Re: [PATCH] ALTER DEFAULT PRIVILEGES with GRANT/REVOKE ON SCHEMAS |
Previous Message | Robert Haas | 2017-01-19 00:05:52 | Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling) |