From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Cody Caughlan <toolbag(at)gmail(dot)com> |
Cc: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Change server encoding after the fact |
Date: | 2011-09-30 19:33:23 |
Message-ID: | 11616.1317411203@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Cody Caughlan <toolbag(at)gmail(dot)com> writes:
> Ok, I see what you mean. This would create a new DB with the proper
> encoding. Which is "fine", and probably what I will do. I guess I see an
> ideal scenario being one where we permanently convert the template encoding
> to UTF8 so going forward I dont have to worry about forgetting to adding the
> encoding= 'UTF8' for every new DB I create.
Well, if you're feeling brave you can mark template0 as having utf8
encoding via a manual update to pg_database. In theory that should
be safe enough. If you know template1 doesn't, and never has, contained
any non-ASCII data, you could do the same to it ... but it would be a
lot safer to drop it and recreate from template0. See
http://wiki.postgresql.org/wiki/Adventures_in_PostgreSQL,_Episode_1
for some context.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Cody Caughlan | 2011-09-30 19:35:22 | Re: Change server encoding after the fact |
Previous Message | Scott Marlowe | 2011-09-30 19:31:52 | Re: Change server encoding after the fact |