Re: Open issues for collations - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Open issues for collations
Date
Msg-id 25764.1302385882@sss.pgh.pa.us
Whole thread Raw
In response to Re: Open issues for collations  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> On mån, 2011-03-28 at 20:02 -0400, Tom Lane wrote:
>> One thing I noticed but didn't push to committing is that the test
>> case has a largely-unnecessary assumption about how the local system's
>> locale names spell "utf8".  We could eliminate that by having it use
>> the trimmed locale names created by initdb.

> I see you went for the latter option.  That works pretty well already.
> I've also been playing around with separating out the "Turkish" tests
> into a separate file.  That would then probably get the remaining
> "latin1" file passing, if we also dropped the encoding mention from this
> error message:

> ERROR:  collation "foo" for encoding "UTF8" does not exist

> I had thought hard about this in the past and didn't want to do it, but
> since we are now making every effort to effectively hide collations with
> the wrong encoding, this would possibly be acceptable.

Not sure.  If we had the test refactored to the point where that was the
only diff you got with a different server encoding, maybe it'd be worth
changing; but right now we're still a long way from there.  I was seeing
this change as mainly targeted towards making the test useful on more
platforms, and since that encoding name is ours and not
platform-specific, it doesn't create any portability issues to show it.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Teaching regex operators about collations
Next
From: Josh Berkus
Date:
Subject: Re: Bug in pg_hba.conf or pg_basebackup concerning replication connections