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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
