client_encoding issue with SQL_ASCII on 8.3 to 10 upgrade

Поиск
Список
Период
Сортировка
От Keith Fiske
Тема client_encoding issue with SQL_ASCII on 8.3 to 10 upgrade
Дата
Msg-id CAODZiv7K+AaJSPk=uqmNa7UQ2va7z_1d_KgVeZzEeqDNvgBn9g@mail.gmail.com
обсуждение исходный текст
Ответы Re: client_encoding issue with SQL_ASCII on 8.3 to 10 upgrade  (Adrian Klaver <adrian.klaver@aklaver.com>)
Re: client_encoding issue with SQL_ASCII on 8.3 to 10 upgrade  (Adrian Klaver <adrian.klaver@aklaver.com>)
Re: client_encoding issue with SQL_ASCII on 8.3 to 10 upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: client_encoding issue with SQL_ASCII on 8.3 to 10 upgrade  (Vick Khera <vivek@khera.org>)
Список pgsql-general
Running into an issue with helping a client upgrade from 8.3 to 10 (yes, I know, please keep the out of support comments to a minimum, thanks :). 

The old database was in SQL_ASCII and it needs to stay that way for now unfortunately. The dump and restore itself works fine, but we're now running into issues with some data returning encoding errors unless we specifically set the client_encoding value to SQL_ASCII. 

Looking at the 8.3 database, it has the client_encoding value set to UTF8 and queries seem to work fine. Is this just a bug in the old 8.3 not enforcing encoding properly?

The other thing I noticed on the 10 instance was that, while the LOCALE was set to SQL_ASCII, the COLLATE and CTYPE values for the restored databases were en_US.UTF-8. Could this be having an affect? Is there any way to see what these values were on the old 8.3 database? The pg_database catalog does not have these values stored back then.

--
Keith Fiske
Senior Database Engineer
Crunchy Data - http://crunchydata.com

В списке pgsql-general по дате отправления:

Предыдущее
От: Jack Gao
Дата:
Сообщение: Re: SQL statement in an error report for deferred constraintviolation.
Следующее
От: Adrian Klaver
Дата:
Сообщение: Re: client_encoding issue with SQL_ASCII on 8.3 to 10 upgrade