Re: Bug #3924: Create Database with another encoding as the encoding from postgres
От | Joe |
---|---|
Тема | Re: Bug #3924: Create Database with another encoding as the encoding from postgres |
Дата | |
Msg-id | 4909C609.5080707@freedomcircle.net обсуждение исходный текст |
Ответ на | Re: Bug #3924: Create Database with another encoding as the encoding from postgres (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Bug #3924: Create Database with another encoding as the encoding from postgres
|
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: