Unable to restore dump due to client encoding issues -- or, when is SQL_ASCII really UTF8
От | Bill Moran |
---|---|
Тема | Unable to restore dump due to client encoding issues -- or, when is SQL_ASCII really UTF8 |
Дата | |
Msg-id | 20070227084327.427868d5.wmoran@collaborativefusion.com обсуждение исходный текст |
Ответы |
Re: Unable to restore dump due to client encoding issues -- or, when is SQL_ASCII really UTF8
|
Список | pgsql-general |
I'm probably missing something painfully obvious here, but it's not obvious to me ... I've pulled a dump of a production database to put it in our lab for various types of testing ... I'm glad I did, as this testing is telling me we'll have issues if we try to upgrade. First off, it's my understanding that with SQL_ASCII "encoding", that PostgreSQL does no checking for valid/invalid characters, per the docs: http://www.postgresql.org/docs/8.2/static/multibyte.html The beginning of the dump file I am restoring has the following: -- -- PostgreSQL database dump -- SET client_encoding = 'SQL_ASCII'; [...] But when I try to pull the dump in with psql, I get the following errors: ERROR: invalid byte sequence for encoding "UTF8": 0xa0 HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlledby "client_encoding". Connecting to the database and issuing "show client_encoding" shows that the database is indeed set to SQL_ASCII. Now ... I'm expecting the server to accept any byte sequence, since we're using SQL_ANSII, but that is (obviously) not the case. Am I missing something obvious here? Grepping the entire dump file shows absolutely no references to UTF8 ... so why is the server trying to validate the byte string as UTF8? -- Bill Moran Collaborative Fusion Inc.
В списке pgsql-general по дате отправления: