Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> As for the patch, I wonder if we want to make this change. I'm not very
> familiar with how unaccent works, but if changes to unicode rules would
> really silently break indexes, it's kinda similar to the collation
> issues caused by glibc updates. And we've generally considered that a
> case of data corruption, I think, so it'd be strange to allow that here.
Yeah. The fact that we have a problem with collation updates doesn't
mean that it's okay to introduce the same problem elsewhere.
Note the extremely large amount of work that's ongoing to try to
track collation changes so we can know whether such an update has
invalidated indexes. Unless this patch comes with equivalent
infrastructure to detect when the unaccent mapping has changed,
I think it should be rejected.
The problem here is somewhat different than for collations, in
that collation changes are hidden behind more-or-less-obscure
library APIs. Here I think we'd "just" have to track whether
the user has changed the associated unaccent mapping file.
However, detecting which indexes are invalidated by such a
change still involves a lot of infrastructure that's not there.
And it'd be qualitatively different, because a config file
change could happen at any time --- we could not relegate
the checks to pg_upgrade or the like.
regards, tom lane