David Johnston <polobo@yahoo.com> writes:
> I guess backward-compatibility concerns forces this solution but after
> thinking through what was happening I was leaning more toward making both
> queries fail. An SRF in a CASE expression seems like a foot-gun to me.
Not really. The cause of the problem in your example is not that the CASE
contains a SRF, but that one arm of the CASE returns a set and the other
does not. There is maybe some argument for making that situation fail ---
essentially, making SETOF be a core part of expression type
identification, such that you can't unify setof text with plain text.
But given that that works in most cases, and was only broken by a
performance optimization added to FuncExpr evaluation (by me :-(),
I think removing the unwarranted assumption from that optimization is the
right thing. I'd definitely not wish to break cases that work as expected
today, but being stricter about expression types would do that.
regards, tom lane
