Re: [COMMITTERS] pgsql: Get rid of USE_WIDE_UPPER_LOWER dependency in trigram constructi

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgresql(dot)org, Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
Subject: Re: [COMMITTERS] pgsql: Get rid of USE_WIDE_UPPER_LOWER dependency in trigram constructi
Date: 2013-04-08 14:36:26
Message-ID: 12780.1365431786@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Simon Riggs 2013-04-08 14:42:40 Re: pgsql: Avoid tricky race condition recording XLOG_HINT
Previous Message Tom Lane 2013-04-08 14:29:20 Re: pgsql: Avoid tricky race condition recording XLOG_HINT

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2013-04-08 14:41:39 Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL)
Previous Message Rodrigo Barboza 2013-04-08 14:27:22 Re: Unrecognized type error (postgres 9.1.4)