From: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: [COMMITTERS] pgsql: Add citext_pattern_ops for citext contrib module |
Date: | 2017-09-19 18:47:26 |
Message-ID: | 35e4bdfa-2f28-36e6-e1e9-de5149432aef@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On 09/19/2017 11:11 AM, Tom Lane wrote:
> Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> writes:
>> This seems to have upset a number or animals in the buildfarm.
> Actually, after looking closer, my advice is just to drop the new
> test cases involving accented letters. It surprises me not in the
> least that those would have nonportable behavior: probably, some
> locales will case-fold them and some won't.
>
> (This does open up some questions about whether the opclass will
> ever be of use for Alexey's original purpose :-()
Actually, it now looks to me like the problem is we forgot to tell
postgres that this data is in utf8. The problem appears to resolve (at
least on my CentOS test box, where I reproduced the buildfarm error) if
I add
set client_encoding = 'utf8';
to the sql file.
Of course UTF8 bytes interpreted as LATIN1 will give results that are
... interesting.
So let's try that first and see if it make the buildfarm go green. Maybe
there's hope for Alexey's purpose after all.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2017-09-19 18:54:51 | pgsql: Set client encoding to UTF8 for the citext regression script |
Previous Message | Andres Freund | 2017-09-19 18:24:17 | Re: Re: [COMMITTERS] pgsql: Perform only one ReadControlFile() during startup. |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2017-09-19 18:49:18 | Re: More efficient truncation of pg_stat_activity query strings |
Previous Message | Pavel Stehule | 2017-09-19 18:45:06 | Re: PoC plpgsql - possibility to force custom or generic plan |