Re: Re: Fixing bug #8228 ("set-valued function called in context that cannot accept a set")

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Johnston <polobo(at)yahoo(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: Fixing bug #8228 ("set-valued function called in context that cannot accept a set")
Date: 2014-01-07 04:49:42
Message-ID: 31688.1389070182@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Johnston <polobo(at)yahoo(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2014-01-07 05:25:42 Re: cleanup in code
Previous Message Kyotaro HORIGUCHI 2014-01-07 04:45:56 Re: Get more from indices.