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

From: Michael Fuhr <mike(at)fuhr(dot)org>
To: Bill Moran <wmoran(at)collaborativefusion(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Unable to restore dump due to client encoding issues -- or, when is SQL_ASCII really UTF8
Date: 2007-02-27 15:52:28
Message-ID: 20070227155228.GA82238@winnie.fuhr.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2007-02-27 16:01:31 Re: select ARRAY[1, 4, 3] @> ARRAY[3, 1] gives ERROR: operator does not exist: integer[] @> integer[] ???
Previous Message Tom Lane 2007-02-27 15:39:35 Re: dropping a master table and all of its partitions?