Commit bb14050 said:
- change order for tsquery, so, users, who has a btree index over tsquery, should reindex it
The last change of this sort also modified pg_upgrade to issue REINDEX
guidance. See old_8_3_invalidate_hash_gin_indexes() in the PostgreSQL 9.4
source. PostgreSQL 9.6 pg_upgrade should do likewise.
Commit 61d66c4 may or may not warrant pg_upgrade treatment:
Fix support of digits in email/hostnames. When tsearch was implemented I did several mistakes in hostname/email
definition rules: 1) allow underscore in hostname what prohibited by RFC 2) forget to allow leading digits
separatedby hyphen (like 123-x.com) in hostname 3) do no allow underscore/hyphen after leading digits in
localpartof email ...
Any index (not just btree) that depends on a text search configuration using
parser pg_catalog.default may need a REINDEX after this change. (Furthermore,
any constraint having such a dependency would need a recheck. That use case
may be less important.) I think the last changes to pg_catalog.default
semantics were 2c265ad (URLs) and 89b0095 (emails), both in 9.0. For those,
we didn't change pg_upgrade or recommend REINDEX in the release notes. We
could call that a relevant precedent and, for this 9.6 change, once again take
no particular action. On the other hand, binary upgrade has matured since its
9.0 birth. Perhaps standards have risen, and pg_upgrade should issue guidance
to REINDEX affected text search indexes. (The guidance could mention the kind
of queries that will notice the difference.) I lean toward having pg_upgrade
address this incompatibility. Other opinions?