Re: Two different methods of sneaking non-immutable data into an index

Merlin Moncure <mmoncure@gmail.com> writes:
> While chatting with Haas off-list regarding how the new array/string
> functions should work (see the thread in its glory here:
> http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg148865.html)
> the debate  morphed into the relative pros and cons about the proposed
> concat() being marked stable vs immutable.  I did some checking into
> how things work now, and found some surprising cases.

Er ... "now" being defined as what?  I can't replicate your results in
HEAD.  In particular, textanycat isn't immutable anymore.

The DROP CAST case is a bit interesting.  We don't record a dependency
on the cast as such, but on the underlying function --- if you'd tried
to drop the function you'd not have been allowed to.  It is a bit
peculiar that dropping the cast causes the meaning of a::text to change,
but I'm not sure there's much we can do about that.  In any case, it
seems like that's not nearly as much of a hazard as doing CREATE OR
REPLACE FUNCTION and changing the computation done by the function.
We could disallow that maybe, but that cure seems worse than the
disease.
        regards, tom lane