On Sat, Oct 3, 2020 at 6:37 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alexander Korotkov <aekorotkov@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
