Re: Performance problem in textanycat/anytextcat

On Sun, May 16, 2010 at 2:59 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Sun, May 16, 2010 at 1:11 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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