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 <andres@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