Re: client_encoding issue with SQL_ASCII on 8.3 to 10 upgrade

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: client_encoding issue with SQL_ASCII on 8.3 to 10 upgrade
Дата
Msg-id 11209.1523895708@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: client_encoding issue with SQL_ASCII on 8.3 to 10 upgrade  (Keith Fiske <keith.fiske@crunchydata.com>)
Ответы Re: client_encoding issue with SQL_ASCII on 8.3 to 10 upgrade  (Keith Fiske <keith.fiske@crunchydata.com>)
Re: client_encoding issue with SQL_ASCII on 8.3 to 10 upgrade  (Keith Fiske <keith.fiske@crunchydata.com>)
Список pgsql-general
Keith Fiske <keith.fiske@crunchydata.com> writes:
> On Mon, Apr 16, 2018 at 12:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> This is not a great idea, no.  You could be getting strange misbehaviors
>> in e.g. string comparison, because strcoll() will expect UTF8 data and
>> will likely not cope well with data that isn't valid in that encoding.

> And pg_controldata was able to show that the CTYPE and COLLATE were UTF8 on
> the old system. If that's the case, do you still think it's a good idea to
> set the COLLATE and CTYPE to "C"?

Well, if the customer's been happy with the behavior of the system so far,
maybe it's all right.  But this is sure the first thing I'd look at if
there are any gripes about its behavior with non-UTF8 strings.  I'd be
especially worried about this if you try to migrate the database to any
new platform, as it's a bet about the behavior of libc not PG itself.

            regards, tom lane


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

Предыдущее
От: Keith Fiske
Дата:
Сообщение: Re: client_encoding issue with SQL_ASCII on 8.3 to 10 upgrade
Следующее
От: Vick Khera
Дата:
Сообщение: Re: client_encoding issue with SQL_ASCII on 8.3 to 10 upgrade