On Sun, May 16, 2010 at 2:59 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Sun, May 16, 2010 at 1:11 PM, Tom Lane <tgl@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.)
I guess my point is that the actual volatility of an expression is
presumably independent of whether it gets inlined. (If inlining is
changing the semantics, that's a problem.) So if inlining is changing
it's apparent volatility, then there's something wrong with the way
we're computing apparent volatility. No?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company