Hannes Dorbath <light@theendofthetunnel.de> writes:
> On 10.10.2005 11:56, Luca Ferrari wrote:
>> gestione_personale=# \l
>> List of databases
>> Name | Owner | Encoding
>> --------------------+-----------+-----------
>> gestione_database | dbmanager | SQL_ASCII
>> gestione_personale | wwwrun | SQL_ASCII
>> template0 | dbmanager | SQL_ASCII
>> template1 | dbmanager | SQL_ASCII
> OK, so you are not using Unicode. I don't know much about the SQL_ASCII
> charset, but I expect it to slightly differ from LATIN1. Type
> SET client_encoding = LATIN1;
No, SQL_ASCII represents the complete absence of any encoding
knowledge. With this database setting, changing client_encoding is a
complete no-op. Postgres will just absorb and re-emit strings exactly
as they were supplied originally, no matter what client_encoding is.
The cause of the unexpected conversions Luca is having trouble with must
be somewhere on the client side. It's not going to be done by Postgres
with this encoding setting.
If you are actively dealing with non-7-bit-ASCII data, using SQL_ASCII
for the database encoding is probably a bad idea, exactly because
Postgres won't help you out at all with converting encodings or
enforcing that data is validly encoded.
regards, tom lane
