Re: 回复:[Internet]Re: [PATCH] Prevent replacement of a function if it's used in an index expression and is not IMMUTABLE - Mailing list pgsql-hackers

From Tom Lane
Subject Re: 回复:[Internet]Re: [PATCH] Prevent replacement of a function if it's used in an index expression and is not IMMUTABLE
Date
Msg-id 1144686.1752077699@sss.pgh.pa.us
Whole thread Raw
In response to 回复:[Internet]Re: [PATCH] Prevent replacement of a function if it's used in an index expression and is not IMMUTABLE  ("sundayjiang(蒋浩天)" <sundayjiang@tencent.com>)
Responses Re: 回复:[Internet]Re: [PATCH] Prevent replacement of a function if it's used in an index expression and is not IMMUTABLE
List pgsql-hackers
"=?utf-8?B?c3VuZGF5amlhbmco6JKL5rWp5aSpKQ==?=" <sundayjiang@tencent.com> writes:
> > The purpose of this patch is to prevent replacing a function via `CREATE OR REPLACE FUNCTION` with a new definition
thatis not marked as `IMMUTABLE`, if the existing function is referenced by an index expression. 
> >
> > Replacing such functions may lead to index corruption or runtime semantic inconsistencies, especially when the
function’soutput is not stable for the same input. 


TBH, I find this proposal to be useless nannyism.  Replacing a
function that is used in an index is problematic if you change its
behavior (that is, its actual output for given inputs) in any way.
Whether it's marked IMMUTABLE is a very minor side point.

If we could detect whether the new definition results in different
behavior, that would be peachy ... but it's equivalent to solving
Turing's halting problem, so I doubt we're going to get there.

So the only really practical thing we could do about that would be
to forbid CREATE OR REPLACE altogether on functions used in indexes.
That proposal is never going to fly, however.

Another way in which the proposed patch is just a band-aid is that
it doesn't detect indirect dependencies, eg if function f() used
in some index calls function g() and you redefine function g().

So as far as I can see, this patch is slowing down function
redefinition in exchange for not much.  We basically have to
trust that people who use user-defined functions in indexes
are aware of the hazard and don't change such functions in
ways that will break their indexes, or at least remember to
REINDEX afterwards.  The portion of that hazard that we can
detect automatically is so small that I think we're just
fooling ourselves (and others) to try at all.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fix comment in btree_gist--1.8--1.9.sql
Next
From: Andres Freund
Date:
Subject: Re: Adding basic NUMA awareness