Re: Unable to restore dump due to client encoding issues -- or, when is SQL_ASCII really UTF8

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Unable to restore dump due to client encoding issues -- or, when is SQL_ASCII really UTF8
Дата
Msg-id 20667.1172592953@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Unable to restore dump due to client encoding issues -- or, when is SQL_ASCII really UTF8  (Bill Moran <wmoran@collaborativefusion.com>)
Ответы Re: Unable to restore dump due to client encoding issues -- or, when is SQL_ASCII really UTF8  (Bill Moran <wmoran@collaborativefusion.com>)
Список pgsql-general
Bill Moran <wmoran@collaborativefusion.com> writes:
> In response to Michael Fuhr <mike@fuhr.org>:
>>> Connecting to the database and issuing "show client_encoding" shows that
>>> the database is indeed set to SQL_ASCII.
>>
>> client_encoding doesn't show the database encoding, it shows the
>> client encoding; execute "show server_encoding" to see the database
>> encoding.

> The database was, indeed, UTF8, which is the default on newer Postgres.

No, it's not necessarily the default --- the default is the encoding
used by whatever locale you initdb'd in.  But what I find odd about the
above is that client_encoding should default to equal server_encoding
unless something on the client side specifically overrides it.  The
above behavior suggests that you've got a .psqlrc or PGCLIENTENCODING
environment variable or some such that is forcing client_encoding to
SQL_ASCII when the server encoding is something different.  That strikes
me as a pretty bad practice; there is use for forcing client_encoding to
something specific, but forcing it to SQL_ASCII seems useless and
possibly dangerous.

            regards, tom lane

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: select ARRAY[1,4,3] @> ARRAY[3,1] gives ERROR: operator does not exist: integer[] @> integer[] ???
Следующее
От: Robert Fitzpatrick
Дата:
Сообщение: Building a record in a function