Re: BUG #13440: unaccent does not remove all diacritics
От | Bruce Momjian |
---|---|
Тема | Re: BUG #13440: unaccent does not remove all diacritics |
Дата | |
Msg-id | 20150903110235.GF23640@momjian.us обсуждение исходный текст |
Ответ на | Re: BUG #13440: unaccent does not remove all diacritics (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #13440: unaccent does not remove all diacritics
|
Список | pgsql-bugs |
On Wed, Sep 2, 2015 at 11:43:52PM -0400, Tom Lane wrote: > Alvaro Herrera <alvherre@2ndquadrant.com> writes: > > Tom Lane wrote: > >> No, not after someone pointed out that it could have strange side-effects > >> on full text search configurations that used unaccent. You'd stop being > >> able to find documents whenever your search term is stripped of accents > >> more thoroughly than before. That might be all right in a new major > >> release (if it documents that you might have to rebuild your FTS indexes > >> and derived tsvector columns). It's not all right in a minor release. > > > Hmm, so what happens if you pg_upgrade FTS indexes? Are they somehow > > marked invalid and a REINDEX is forced? > > No. They're not broken in a fundamental way, it's just that certain > search terms no longer find document words you might think they should > match. Oleg and Teodor argued back at the beginning of the FTS stuff > that this sort of thing wasn't critical, and I agree --- but we shouldn't > change the mapping in minor releases. Uh, I thought the whole discussion was whether this should be changed in head _and_ 9.5, or just head. I didn't think anyone was suggesting minor releases. We don't consider a 9.5 change to be a minor release change at this point, do we? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
В списке pgsql-bugs по дате отправления: