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.
regards, tom lane