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

On Wed, Aug 4, 2010 at 7:00 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Merlin Moncure <mmoncure(at)gmail(dot)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(at)postgresql(dot)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.

ah, my mistake. I'm using a fairly old build of 9.0.

> 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.

yep (the textanycat was much more interesting to me)

merlin