Tom Lane-2 wrote
> David Johnston <
> polobo@
> > writes:
>> The whole "varchar/varchar(30)" discrepancy is bothersome and since the
>> example forces a function-call via the use of "lower(...)", and doesn't
>> test
>> the non-function situation, I am concerned this patch is incorrect.
>
> The reason casting to varchar(30) fails is that that results in invocation
> of a function (to enforce the length limit). Casting to varchar is just a
> RelabelType operation, which doesn't have two different code paths for
> set and not-set inputs.
>
> I did check the patch against your original example, but I thought using
> lower() made the purpose of the regression test case more apparent.
Yeah, I caught that part. My focus was on the non-function version.
Not being able to apply the patch and test myself it sounds like you likely
made the function-invocation version succeed along with the original
re-label-only version.
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. SRF
in the select-list is someone of a foot-gun too but understandable given the
recency of the addition of LATERAL to our toolbox.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Fixing-bug-8228-set-valued-function-called-in-context-that-cannot-accept-a-set-tp5785622p5785636.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.