From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [COMMITTERS] pgsql: Get rid of USE_WIDE_UPPER_LOWER dependency in trigram constructi |
Date: | 2013-04-08 14:58:23 |
Message-ID: | m2r4ilgjcg.fsf@2ndQuadrant.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2013-04-08 16:04:37 | Re: pgsql: README comments on checksums on page holes. |
Previous Message | Andres Freund | 2013-04-08 14:54:03 | Re: pgsql: Avoid tricky race condition recording XLOG_HINT |
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2013-04-08 15:02:57 | Re: pg_dump with postgis extension dumps rules separately |
Previous Message | Rodrigo Barboza | 2013-04-08 14:44:04 | Re: Unrecognized type error (postgres 9.1.4) |