Re: Functions used in index definitions shouldn't be changed

Antonin Houska <ah(at)cybertec(dot)at> writes:
> Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> wrote:
>> Currently it is possible to change the behaviour of a function with
>> CREATE OR REPLACE FUNCTION even if the function is part of an index definition.
>>
>> I think that should be forbidden, because it is very likely to corrupt
>> the index. I expect the objection that this would break valid use cases
>> where people know exactly what they are doing, but I believe that this
>> is a footgun for inexperienced users that should be disarmed.
>>
>> I'd also opt for forbidding behaviour changing modifications with ALTER FUNCTION
>> for functions used in index definitions, specifically altering strictness.
>>
>> Attached is a patch implementing a fix.

> Instead of adding extra check, shouldn't you just ensure that
> DEPENDENCY_INTERNAL is the dependency type and let the existing logic do the work?

The dependency logic only prohibits DROP, not ALTER, so changing the
dependency type wouldn't be enough to accomplish that. But I dislike the
entire concept, so implementation details are not that interesting.

A comparable issue is that alteration of text search configurations may
partially invalidate precomputed tsvector columns and indexes based on
tsvector data. We discussed whether we should prohibit that somehow
and explicitly decided that it would be a bad idea. In the text search
case, changes like adding stop words are common and don't meaningfully
invalidate indexes. In some cases you may decide that you need to
recompute the tsvector data, but that decision should be left to the
user.

I think that pretty much the same thing applies to functions used in
indexes. There are too many use-cases where alterations don't
meaningfully impact the stored data for us to get away with a blanket
prohibition. (I'm pretty sure that this has been discussed in the
past, too. If Albe really wants to push the point he should look
up the previous discussions and explain why the decision was wrong.)

regards, tom lane