Re: pgsql: Get rid of USE_WIDE_UPPER_LOWER dependency in trigram constructi
От | Dimitri Fontaine |
---|---|
Тема | Re: pgsql: Get rid of USE_WIDE_UPPER_LOWER dependency in trigram constructi |
Дата | |
Msg-id | m2a9p9mogd.fsf@2ndQuadrant.fr обсуждение исходный текст |
Ответ на | pgsql: Get rid of USE_WIDE_UPPER_LOWER dependency in trigram constructi (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql: Get rid of USE_WIDE_UPPER_LOWER dependency
in trigram constructi
|
Список | pgsql-committers |
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. What do you think? -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
В списке pgsql-committers по дате отправления: