Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-general by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group