From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bill Moran <wmoran(at)collaborativefusion(dot)com> |
Cc: | Michael Fuhr <mike(at)fuhr(dot)org>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Unable to restore dump due to client encoding issues -- or, when is SQL_ASCII really UTF8 |
Date: | 2007-02-27 16:15:53 |
Message-ID: | 20667.1172592953@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Bill Moran <wmoran(at)collaborativefusion(dot)com> writes:
> In response to Michael Fuhr <mike(at)fuhr(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-02-27 16:34:41 | Re: How to debug this crash? |
Previous Message | Tom Lane | 2007-02-27 16:01:31 | Re: select ARRAY[1, 4, 3] @> ARRAY[3, 1] gives ERROR: operator does not exist: integer[] @> integer[] ??? |