Skip site navigation (1) Skip section navigation (2)

Re: 7.4.13 initdb fails on Turkish locale

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 (view raw or flat)
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

In response to

Responses

pgsql-bugs by date

Next:From: Devrim GUNDUZDate: 2006-06-18 10:16:12
Subject: Re: 7.4.13 initdb fails on Turkish locale
Previous:From: Devrim GUNDUZDate: 2006-06-17 22:23:20
Subject: Re: 7.4.13 initdb fails on Turkish locale

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group