Re: initdb of regression test failed.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: 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 19:26:53
Message-ID: 5409.1191526013@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> writes:
> 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).

I'm not very happy with this proposal, because for people who don't
actually care about non-ASCII data (which is still a lot of people),
forcing UTF-8 as the default encoding will impose pretty substantial
overhead compared to SQL_ASCII --- it turns on all those
multibyte-encoding checks.

Implicitly selecting --no-locale doesn't seem like a big step forward
either, since then you've just given up whatever you might have learned
from the locale setting. Besides, if that's the behavior the user
wants, he can specify it.

I still think that what we should try to do in the default case is find
a locale that is the same language but UTF-8 encoding.

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

Well, that just leaves me wondering what encoding the localized messages
would be presented in ...

regards, tom lane

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Neil Conway 2007-10-04 20:03:22 Re: Connection Pools and DISCARD ALL
Previous Message Simon Riggs 2007-10-04 14:50:16 Re: Connection Pools and DISCARD ALL