On Sun, May 16, 2010 at 2:59 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.)
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
