Robert Haas <robertmh...@gmail.com> writes:
> On Sun, May 16, 2010 at 1:11 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> No, only the ones that are built on top of other functions that aren't
>> immutable.
> Built on top of? I don't get it. It seems like anything of the form
> immutablefunction(volatilefunction()) is vulnerable to this,
Uh, no, you misunderstand completely. The problematic case is where the
function's own expansion contains a non-immutable function. In
particular, what we have for these functions is that textanycat(a,b)
expands to a || b::text, and depending on what the type of b is, the
cast from that to text might not be immutable. This is entirely
independent of whether the argument expressions are volatile or not.
Rather, the problem is that inlining the function definition could
by itself increase the expression's apparent volatility. (Decreasing
the volatility is not problematic. Increasing it is.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
