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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
