Re: Unable to restore dump due to client encoding issues -- or, when is SQL_ASCII really UTF8 - Mailing list pgsql-general

From Michael Fuhr
Subject Re: Unable to restore dump due to client encoding issues -- or, when is SQL_ASCII really UTF8
Date
Msg-id 20070227155228.GA82238@winnie.fuhr.org
Whole thread Raw
In response to Re: Unable to restore dump due to client encoding issues -- or, when is SQL_ASCII really UTF8  (Bill Moran <wmoran@collaborativefusion.com>)
List pgsql-general
On Tue, Feb 27, 2007 at 10:31:47AM -0500, Bill Moran wrote:
> The database was, indeed, UTF8, which is the default on newer Postgres.

initdb determines the encoding from your environment.  If you're
on a Unix-like platform run "env | grep UTF" and you'll probably
see that LANG and/or LC_* is set to something like "en_US.UTF-8".

> I find it odd that I can't alter the encoding after database creation,
> but in this case it wasn't a big deal, as it's a lab system and I can
> just back up a few steps and start over.

Altering the database encoding would mean that all string data would
have to be checked and possibly converted.  Doing that on a large
running system would be problematic; it would probably be just as
easy to dump and restore the entire database.

--
Michael Fuhr

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: dropping a master table and all of its partitions?
Next
From: Tom Lane
Date:
Subject: Re: select ARRAY[1,4,3] @> ARRAY[3,1] gives ERROR: operator does not exist: integer[] @> integer[] ???