Hi,
On 2017-06-02 22:53:00 -0400, Tom Lane wrote: > I think you've got enough on your plate. I can take care of whatever > we decide to do here. Thanks. > Andres Freund <and...@anarazel.de> writes: > >> Another possibility is to say that we've broken this situation > >> irretrievably and we should start throwing errors for SRFs in > >> places where they'd be conditionally evaluated. That's not real > >> nice perhaps, but it's better than the way things are right now. > > > I'd be ok with that too, but I don't really see a strong need so far. > > The argument for this way is basically that it's better to break > apps visibly than silently. Right, I got that. > The behavior for SRF-inside-CASE is > not going to be the same as before even if we implement the fix > I suggest above, and it's arguable that this new behavior is not > at all intuitive. Yea, I'm not a big fan of the either the pre v10 or the v10 behaviour of SRFs inside coalesce/case. Neither is really resonable imo - I'm not sure a reasonable behaviour even exists. IIRC I'd argued in the original SRF thread that we should just throw an error, and I think we'd concluded that we'd not do so for now. > I'm not really sure which way to jump, which is why I was hoping > for some discussion here. There not really being an intuitive behaviour seems to be a bit of a reason to disallow. Another argument that I can see is that it'll be easier to allow it again later, than to do the reverse. But I think the new behaviour can also be useful, and I suspect not that many people will hit this... - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
