Hi,

Description of problem: initdb fails on tr_TR.UTF-8. OS is Fedora Core 5
on a 32 bit platform, and an up2date system.

Version-Release number of selected component (if applicable): PostgreSQL
7.4.13.

How reproducible: Always

Steps to Reproduce:
1. Compile PostgreSQL 7.4.13
2. Create data dir
3. Run initdb with --locale=tr_TR.UTF-8

Actual results:

-bash-3.1$ bin/initdb -D data/ --locale=tr_TR.UTF-8
The files belonging to this database system will be owned by user
"postgres".
This user must also own the server process.

The database cluster will be initialized with locale tr_TR.UTF-8.
<snipped>
creating template1 database in data//base/1... FATAL: XX000: failed to
initialize DateStyle to "ISO, MDY"
LOCATION: InitializeGUCOptions, guc.c:1881

initdb: failed

Expected results:
The initdb should succeed.

Additional information:

AFAIR we have fixed this early 7.4 series, but it is back now. I'm not
sure when this reappeared. I haven't tested 7.4.X for a long time.

Regards,
--
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/



---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Devrim GUNDUZ <devrim@commandprompt.com> writes:
> AFAIR we have fixed this early 7.4 series, but it is back now. I'm not
> sure when this reappeared. I haven't tested 7.4.X for a long time.

No, that's never worked in 7.4 ... we didn't add the pg_strcasecmp
code until 8.0 devel cycle.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Hi Tom,

On Sat, 2006-06-17 at 18:12 -0400, Tom Lane wrote:
> Devrim GUNDUZ <devrim@commandprompt.com> writes:
> > AFAIR we have fixed this early 7.4 series, but it is back now. I'm
> not
> > sure when this reappeared. I haven't tested 7.4.X for a long time.
>
> 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/s...ase-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.
=============================

Regards,

--
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/



---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Devrim GUNDUZ <devrim@commandprompt.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/s...ase-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...2/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...5/msg00037.php
which seems entirely unreasonable to me.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Hi,

On Sat, 2006-06-17 at 19:05 -0400, Tom Lane wrote:
> AFAICT the only real solution would be to introduce pg_strcasecmp
> into 7.4, ie backport this patch:
> http://archives.postgresql.org/pgsql...5/msg00037.php
> which seems entirely unreasonable to me.

I was just testing 7.4, and I agree with you -- there is no need to fix
this problem on a relatively old branch.

Regards,
--
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/



---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend