Re: initdb of regression test failed.

From: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-patches(at)postgresql(dot)org, "Hiroshi Saito" <z-saito(at)guitar(dot)ocn(dot)ne(dot)jp>
Subject: Re: initdb of regression test failed.
Date: 2007-10-04 10:11:27
Message-ID: 20071004171712.BD1E.ITAGAKI.TAKAHIRO@oss.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches


Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> > initdb -E UTF8 --locale=Japanese_Japan.932 -- CP932 is SJIS in nature
>
> Hmm, but does that really work safely? I think varstr_cmp() does work,
> because it forces our data into wchar format and then calls wcscoll().
> The thing that scares me is that various random other operating-system
> calls might deliver strings in an unexpected encoding. We've been
> through similar problems with timezone names reported by strftime, for
> example.

Hmm, I see we might need to replace all locale-aware functions to
wchar_t versions, for example, wcsftime instead of strftime.
It requires more tests. It should be saved for 8.4.

The attached is the second plan. It uses UTF-8 and locale=C when
the default locale encoding is not supported and none of encoding and
locale are passed to initdb. It would help users who use the default
settings (including regression test).

At the moment, it reset all of lc_* variables, but it might be possible
use the default locale at lc_messages, lc_monetary, lc_numeric and lc_time
even if lc_collate and lc_ctype are reset to C.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

Attachment Content-Type Size
utf8-nolocale-on-failure.patch application/octet-stream 3.2 KB

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Simon Riggs 2007-10-04 14:11:22 Connection Pools and DISCARD ALL
Previous Message Hiroshi Saito 2007-10-04 07:02:11 Re: initdb of regression test failed.