Thread: [HACKERS] Re: [COMMITTERS] pgsql: Add citext_pattern_ops for citext contribmodule
[HACKERS] Re: [COMMITTERS] pgsql: Add citext_pattern_ops for citext contribmodule
From
Andrew Dunstan
Date:
On 09/19/2017 08:35 AM, Andrew Dunstan wrote: > Add citext_pattern_ops for citext contrib module > > This is similar to text_pattern_ops. > This seems to have upset a number or animals in the buildfarm. I could create a third output file, but I am seriously questioning the point of all this, if we are prepared to accept any result from these functions and operators, depending on locale. Maybe it would be better simply to test that the result is not null and have done with it. Thoughts? cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Add citext_pattern_ops forcitext contrib module
From
Simon Riggs
Date:
On 19 September 2017 at 15:22, Andrew Dunstan <andrew.dunstan@2ndquadrant.com> wrote: > > > On 09/19/2017 08:35 AM, Andrew Dunstan wrote: >> Add citext_pattern_ops for citext contrib module >> >> This is similar to text_pattern_ops. >> > > This seems to have upset a number or animals in the buildfarm. > > I could create a third output file, but I am seriously questioning the > point of all this, if we are prepared to accept any result from these > functions and operators, depending on locale. Maybe it would be better > simply to test that the result is not null and have done with it. Thoughts? It makes sense to have a fully detailed output in at least one parameter setting. How about use the new psql feature for \if to skip tests if the local is different to the one for which we have detailed test results? -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Add citext_pattern_ops for citext contrib module
From
Tom Lane
Date:
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> This seems to have upset a number or animals in the buildfarm.
Looks like all the ones that are testing in en_US locale.
> I could create a third output file, but I am seriously questioning the
> point of all this,
What locale did you use to create citext_1.out? We've never before
needed more than one output file for non-C locales.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Add citext_pattern_ops for citext contrib module
From
Tom Lane
Date:
Andrew Dunstan <andrew.dunstan@2ndquadrant.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 :-()
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Add citext_pattern_ops forcitext contrib module
From
Andrew Dunstan
Date:
On 09/19/2017 11:11 AM, Tom Lane wrote: > Andrew Dunstan <andrew.dunstan@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Add citext_pattern_ops for citext contrib module
From
Tom Lane
Date:
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> On 09/19/2017 11:11 AM, Tom Lane wrote:
>> 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.
> 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.
That took care of one source of problems, but I wouldn't have expected it
to resolve all the problems ... and it didn't.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Add citext_pattern_ops forcitext contrib module
From
Andrew Dunstan
Date:
On 09/19/2017 02:47 PM, Andrew Dunstan wrote: > > On 09/19/2017 11:11 AM, Tom Lane wrote: >> Andrew Dunstan <andrew.dunstan@2ndquadrant.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. *sigh* That worked in a couple of instances but crashed and burned elsewhere. I'll just disable the multi-byte tests as Tom suggests. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers