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
|
Список | 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 по дате отправления: