Hannes Dorbath <light@xxxxxxxxxxxxxxxxxxxx> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
