From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Boh Yap <bhyz00(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #5178: make check fails because of locale en_AU.US-ASCII |
Date: | 2009-11-11 19:27:32 |
Message-ID: | 11579.1257967652@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On tis, 2009-11-10 at 17:15 -0500, Tom Lane wrote:
>> I was wondering what we ought to do about this. I can't find any clear
>> documentation about these locales on my Mac, but it sure looks like they
>> are effectively encoding-agnostic, which means that it might be
>> reasonable to default to SQL_ASCII --- anyway there is certainly not any
>> basis for selecting a different default. However, if we want to do that
>> it's not a one-liner change, because the API for
>> pg_get_encoding_from_locale isn't designed to allow for this.
> Well, --locale=C results in encoding SQL_ASCII, and the encoding of
> locale C is in fact by definition US-ASCII. So any locale that
> explicitly claims it is US-ASCII should have the same result.
Okay. Then we need to fix pg_get_encoding_from_locale to distinguish
"I don't know the locale's encoding" from "I know the encoding and it's
SQL_ASCII". I'm inclined to make it return -1 for the former,
which is a bit ugly but should be safe. The alternative is a separate
boolean output, which seems uglier. Comments?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2009-11-11 20:04:06 | Re: BUG #5178: make check fails because of locale en_AU.US-ASCII |
Previous Message | Sachin Srivastava | 2009-11-11 19:04:04 | Re: BUG #5179: Installation fails |