On Sat, Oct 3, 2020 at 6:37 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Alexander Korotkov <aekorot...@gmail.com> writes: > > I personally don't have an exact understanding of how strict we are > > about marking functions immutable. For example, > > to_tsvector(regconfig, text) is immutable. > > Yeah. This is in fact wrong, because a TS configuration can *very* > easily be changed by the user. We held our noses and did it anyway > to allow tsvector results to be stored in indexes, figuring that > (a) we'd put it on the user's head to reindex when necessary, and > (b) in most situations, small changes in a TS configuration don't > make an old tsvector index unusable --- at worst, some searches > will fail that should have succeeded. (I'm not entirely sure that > I believe (b), but that was the argument that was advanced.) > > I do not think we'd accept such a compromise if it were put forward > today. The project's standards for such things have tightened over > time, as evidenced by the work that's going towards collation > change detection. > > It's also worth noting that the consequences of an out-of-date > index for unaccent seem likely to be worse than they are for > tsvectors. It's not hard to imagine somebody making a unique > index on an unaccent result, and then setting themselves up for > dump/reload failures by changing the unaccent rules. Nobody > builds unique indexes on tsvectors.
Tom, thank you for the clarification. Now I get more understanding on the project policy here. I agree that we shouldn't mark unaccent() as immutable in the current infrastructure. ------ Regards, Alexander Korotkov
