Re: Bug #3924: Create Database with another encoding as the encoding from postgres

From: Joe <dev(at)freedomcircle(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Bug #3924: Create Database with another encoding as the encoding from postgres
Date: 2008-10-30 14:34:49
Message-ID: 4909C609.5080707@freedomcircle.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2008-10-30 14:39:58 Re: Bug #3924: Create Database with another encoding as the encoding from postgres
Previous Message Tom Lane 2008-10-30 14:03:34 Re: Bug #3924: Create Database with another encoding as the encoding from postgres