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
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 |