Re: Open issues for collations

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Open issues for collations
Date: 2011-04-09 21:51:22
Message-ID: 25764.1302385882@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On mn, 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2011-04-09 22:15:32 Re: Bug in pg_hba.conf or pg_basebackup concerning replication connections
Previous Message Tom Lane 2011-04-09 21:40:27 Teaching regex operators about collations