X-Original-To: pgsql-admin-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id DE2ADD1B17B; Sat, 17 Jul 2004 18:18:17 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 77751-05; Sat, 17 Jul 2004 21:18:17 +0000 (GMT) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by svr1.postgresql.org (Postfix) with ESMTP id E644CD1B1CD; Sat, 17 Jul 2004 18:18:14 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.11/8.12.11) with ESMTP id i6HLIGSN016995; Sat, 17 Jul 2004 17:18:16 -0400 (EDT) To: "Dario V. Fassi" Cc: pgsql-jdbc@postgresql.org, pgsql-admin@postgresql.org Subject: Re: Migrate postgres databases from SQL_ASCII to UNICODE encoding In-reply-to: <40F98613.1060405@sistemat.com.ar> References: <40F98613.1060405@sistemat.com.ar> Comments: In-reply-to "Dario V. Fassi" message dated "Sat, 17 Jul 2004 17:03:31 -0300" Date: Sat, 17 Jul 2004 17:18:16 -0400 Message-ID: <16994.1090099096@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.0 tagged_above=0.0 required=5.0 tests= X-Spam-Level: X-Archive-Number: 200407/201 X-Sequence-Number: 14269 "Dario V. Fassi" writes: > A simple question, we need to migrate many (>20) postgres databases from > SQL_ASCII encoding to UNICODE encoding, over a 7.3.6 server. SQL_ASCII is not an encoding (it's more like the absence of knowledge about an encoding). What is the data actually stored as? > With Dump/Restore , we get an error (Invalid Unicode) in any field that > has a 8 bits character coming from the SQL_ASCII , even setting the > client_encoding to WIN, ISO-8859-1, and others encodings. It might work to just UPDATE pg_database to set datencoding to the correct value reflecting what you have actually stored. You might then need to REINDEX any indexes on textual columns, but I don't think anything else would go wrong. If you have a mishmash of different encodings in a single database, then of course there is no simple solution; you are in for some pain while you try to fix the data. regards, tom lane