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

From: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
To: "Tom Lane *EXTERN*" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Antonin Houska <ah(at)cybertec(dot)at>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Functions used in index definitions shouldn't be changed
Date: 2014-11-20 18:56:58
Message-ID: A737B7A37273E048B164557ADEF4A58B17DA24CD@ntex2010a.host.magwien.gv.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> 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.

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

I don't think that there is a universally compelling right or wrong to
questions like this, it is more a matter of taste. Is it more important to protect
the casual DBA from hurting himself or herself, or is it more important to
provide a well honed scalpel for the experienced surgeon?

It seems that more people lean in the latter direction, so I'll cease and desist.

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-11-20 18:57:25 Re: group locking: incomplete patch, just for discussion
Previous Message Peter Geoghegan 2014-11-20 18:30:44 Re: Doing better at HINTing an appropriate column within errorMissingColumn()