BUG #5178: make check fails because of locale en_AU.US-ASCII

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