Thread: BUG #5178: make check fails because of locale en_AU.US-ASCII
The following bug has been logged online: Bug reference: 5178 Logged by: Boh Yap Email address: bhyz00@gmail.com PostgreSQL version: 8.4.1 Operating system: Mac OSX 10.5.8 Description: make check fails because of locale en_AU.US-ASCII Details: installing from src, after doing ./configure and make, make check failed, when trying to initdb, with this message in log: could not determine encoding for locale "en_AU.US-ASCII": codeset is "US-ASCII" but "en_AU.US-ASCII" is in /usr/share/locale my LANG, LC_CTYPE, LC_COLLATE all contain the above locale value. did not proceed with install as I suspect initdb will fail.
On tis, 2009-11-10 at 20:45 +0000, Boh Yap wrote: > make check > failed, when trying to initdb, with this message in log: > > could not determine encoding for locale "en_AU.US-ASCII": codeset is > "US-ASCII" Try using a different locale.
Peter Eisentraut <peter_e@gmx.net> writes:
> On tis, 2009-11-10 at 20:45 +0000, Boh Yap wrote:
>> could not determine encoding for locale "en_AU.US-ASCII": codeset is
>> "US-ASCII"
> Try using a different locale.
Or specify an encoding explicitly.
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.
regards, tom lane
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.
Peter Eisentraut <peter_e@gmx.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
On ons, 2009-11-11 at 14:27 -0500, Tom Lane wrote: > 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, Makes sense. The other alternative is to create a real 7-bit ASCII encoding, but I doubt it's worth the effort.
Peter Eisentraut <peter_e@gmx.net> writes:
> The other alternative is to create a real 7-bit ASCII encoding, but I
> doubt it's worth the effort.
Yeah, I considered that for about two seconds ...
regards, tom lane