From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Devrim GUNDUZ <devrim(at)commandprompt(dot)com> |
Cc: | "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: 7.4.13 initdb fails on Turkish locale |
Date: | 2006-06-17 23:05:20 |
Message-ID: | 24473.1150585520@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Devrim GUNDUZ <devrim(at)commandprompt(dot)com> writes:
> On Sat, 2006-06-17 at 18:12 -0400, Tom Lane wrote:
>> No, that's never worked in 7.4 ... we didn't add the pg_strcasecmp
>> code until 8.0 devel cycle.
> I mean this one:
> http://www.postgresql.org/docs/7.4/static/release-7-4-2.html
> Partial fix for Turkish-locale issues
> initdb will succeed now in Turkish locale, but there are still some
> inconveniences associated with the i/I problem.
Hmm. I wonder what we tested back then? I traced through it, and the
reason it's failing is that strcasecmp() is telling assign_datestyle()
that "iso" and "ISO" are not equal, and as far as I can tell none of the
relevant code has changed in the 7.4 branch. Maybe the release note is
just wrong.
I dug around in the archives and found this discussion:
http://archives.postgresql.org/pgsql-hackers/2004-02/msg00709.php
That patch was never committed because it didn't pass regression.
AFAICT the only real solution would be to introduce pg_strcasecmp
into 7.4, ie backport this patch:
http://archives.postgresql.org/pgsql-committers/2004-05/msg00037.php
which seems entirely unreasonable to me.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Devrim GUNDUZ | 2006-06-18 10:16:12 | Re: 7.4.13 initdb fails on Turkish locale |
Previous Message | Devrim GUNDUZ | 2006-06-17 22:23:20 | Re: 7.4.13 initdb fails on Turkish locale |