Hi Tom,
Tom Lane wrote:
> Why does it have to be LATIN1? If your answer is "my client code deals
> in LATIN1", just set client_encoding = LATIN1. You could do that with
> ALTER DATABASE SET or possibly ALTER USER SET so that it's transparent
> to the clients.
>
The client code is primarily encoding-agnostic at this time. However,
the database was just migrated from SQL_ASCII after undergoing a
text-column "cleanup" (like removing Win-1252 funny quotes) so I'm not
eager to migrate to UTF8 right away, particularly when we're not
convinced we need it (although it seems eventually we'll do that).
Going back to my options, are you saying that if I re-initdb the 8.3
cluster to UTF8, restore the LATIN1 db as UTF8, and then do "set
client_encoding = LATIN1" in the application code, then everything will
work fine, even if the machine locale remains en_US.iso88591? And, at
least in theory, if a non-LATIN1 character (like 0x92) is presented to
the converted database, will it be stored as is or silently transformed
(or will an error be issued)?
Joe
