Re: pgsql: Get rid of USE_WIDE_UPPER_LOWER dependency in trigram constructi
От | Stefan Kaltenbrunner |
---|---|
Тема | Re: pgsql: Get rid of USE_WIDE_UPPER_LOWER dependency in trigram constructi |
Дата | |
Msg-id | 5165B379.3020201@kaltenbrunner.cc обсуждение исходный текст |
Ответ на | Re: pgsql: Get rid of USE_WIDE_UPPER_LOWER dependency in trigram constructi (Dimitri Fontaine <dimitri@2ndQuadrant.fr>) |
Список | pgsql-committers |
On 04/08/2013 10:11 AM, Dimitri Fontaine wrote: > 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? > > $ pg_checkupgrade -d "connection=string" > upgrade.sql > NOTICE: checking 9.3 upgrade release notes > WARNING: RN-93-0001 index idx_trgm_abc is not on-disk compatible with 9.3 > WARNING: TN-93-0012 … > WARNING: This script is NOT comprehensive, read release notes at … > > The target version would be hard coded on the binary itself for easier > maintaining of it, and that proposal includes a unique identifier for > any release note worthy warning that we know about, that would be > included in the output of the program. > > I think most of the checks would only have to be SQL code, and some of > them should include running some binary code the server side. When > that's possible, we could maybe expose that binary code in a server side > extension so as to make the client side binary life's easier. That would > also be an excuse for the project to install some upgrade material on > the old server, which has been discussed in the past for preparing > pg_upgrade when we have a page format change. given something like this also will have to be dealt with by pg_upgrade, why not fold it into that (like into -c) completly and recommend running that? on the flipside if people don't read the release notes they will also not run any kind of binary/script mentioned there... Stefan
В списке pgsql-committers по дате отправления: