Thread: Re: [COMMITTERS] pgsql: Get rid of USE_WIDE_UPPER_LOWER dependency in trigram constructi
Re: [COMMITTERS] pgsql: Get rid of USE_WIDE_UPPER_LOWER dependency in trigram constructi
From
Tom Lane
Date:
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes: > Tom Lane <tgl@sss.pgh.pa.us> writes: >> If there is anybody still using Postgres on machines without wcstombs() or >> towlower(), and they have non-ASCII data indexed by pg_trgm, they'll need >> to REINDEX those indexes after pg_upgrade to 9.3, else searches may fail >> incorrectly. It seems likely that there are no such installations, though. > Those conditions seem just complex enough to require a test script that > will check that for you. What if we created a new binary responsible for > auto checking all those release-note items that are possible to machine > check, then issue a WARNING containing the URL to the release notes you > should be reading, and a SQL script (ala pg_upgrade) to run after > upgrade? How exactly would you know whether the previous installation was built without HAVE_WCSTOMBS/HAVE_TOWLOWER? That's not exposed anywhere reliable. And it's not out of the question that somebody upgrading to a newer PG version might upgrade his OS too, so I would not think that checking what configure says now is trustworthy. In general, though, this suggestion seems about two orders of magnitude more work than the particular case justifies. We might want to think about something like it for future releases, but it's not likely to happen for 9.3. regards, tom lane
Re: [COMMITTERS] pgsql: Get rid of USE_WIDE_UPPER_LOWER dependency in trigram constructi
From
Dimitri Fontaine
Date:
Tom Lane <tgl@sss.pgh.pa.us> writes: > How exactly would you know whether the previous installation was built > without HAVE_WCSTOMBS/HAVE_TOWLOWER? That's not exposed anywhere > reliable. And it's not out of the question that somebody upgrading to > a newer PG version might upgrade his OS too, so I would not think that > checking what configure says now is trustworthy. Oh, it's even worse than I imagined then. If you don't know where to find the information, maybe the release notes should just propose to REINDEX in any case? > In general, though, this suggestion seems about two orders of magnitude > more work than the particular case justifies. We might want to think > about something like it for future releases, but it's not likely to > happen for 9.3. Yeah, I've been thinking that it's the case after sending the email proposal. It might just be some accumulative effect that leads me to that proposal. I still think that a tool able to asses if you're concerned by "reindex gist indexes on that datatype" or suchlike would be really good to have. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support