Re: Two different methods of sneaking non-immutable data into an index - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Two different methods of sneaking non-immutable data into an index
Date
Msg-id 16753.1280962815@sss.pgh.pa.us
Whole thread Raw
In response to Two different methods of sneaking non-immutable data into an index  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: Two different methods of sneaking non-immutable data into an index
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Alex Hunsaker
Date:
Subject: Re: Drop one-argument string_agg? (was Re: [BUGS] string_agg delimiter having no effect with order by)
Next
From: Tom Lane
Date:
Subject: Re: Drop one-argument string_agg? (was Re: [BUGS] string_agg delimiter having no effect with order by)