Marko Karppinen <[EMAIL PROTECTED]> writes:
> I think this interaction between the locale and server_encoding is
> confusing. Is there any use case for running an incompatible mix?
In hindsight we should probably not have invented per-database encoding
selection, since it's so fragile to use in co
Tatsuo Ishii wrote:
initdb could even emit a warning if the --encoding option was
used without also specifying --no-locale.
Please don't do that. Most Asian chasets does not work with locale
enabled PostgreSQL installation. i.e. it returns WRONG SELECT
results. I've been telling this to Japanese us
Marko Karppinen wrote:
I think this interaction between the locale and server_encoding is
confusing. Is there any use case for running an incompatible mix?
If not, would it not make sense to fetch initdb's default database
encoding with nl_langinfo(CODESET) instead of using SQL_ASCII?
Peter Eisentr
Marko Karppinen wrote:
> I think this interaction between the locale and server_encoding is
> confusing. Is there any use case for running an incompatible mix?
> If not, would it not make sense to fetch initdb's default database
> encoding with nl_langinfo(CODESET) instead of using SQL_ASCII?
This
Tom Lane wrote:
This code will only work if the database is running under an LC_CTYPE
setting that implies the same encoding specified by server_encoding.
However, I don't see that as a fatal objection, because in point of
fact
the existing upper/lower code assumes the same thing.
I think this int
Le jeudi 13 Mai 2004 04:42, Tom Lane a Ãcrit :
> I got tired of reading complaints about how upper/lower don't work with
> Unicode, so I went and prototyped a solution. ÂThe attached code uses
> the C99-standard functions mbstowcs and wcstombs to convert to and from
> a "wchar_t[]" representation t
