Re: [HACKERS] Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling) |
Дата | |
Msg-id | 17806.1484784484@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Implement targetlist SRFs using ROWS FROM() (wasChanged SRF in targetlist handling) (Robert Haas <robertmhaas@gmail.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: