Good to know that you found a way to make it work. As for the database issue - whether its encoding should be unicode or latin1 - it looks that it can be one or another, as long as strings are converted to/from unicode for aolserver correctly in case where database encoding were latin1/latin2. The PGCLIENTENCODING='UNICODE' in my /etc/profile cares for that.
As for myself I'd rather not have the database in unicode, despite the fact that it works for you. For once, sometimes I'm connecting to the database from a Windows box via ODBC and this client uses yet another encoding (windows1250), for which the conversion can be done by postgres, but only if latin2 encoding is used on the server's end.
The other reason is, I want to avoid problems similar to these you experienced: getting a mix of encodings within the database in case some strings are entered via forms, some from psql shell, some from dump files and I forget to set encoding info for each 'way' correctly. By setting database encoding to latin2 I can be sure at least the psql input is right and dump files can be checked visually before importing them into datbase. By the way, while in psql the
encoding command comes very handy when database encoding differs from terminal encoding.
My third reason is that I am not yet aware of proper locale files
for pl_PL (Polish) for Unicode. Without them I can not depend on Postgres with correct sorting, upper(), lower(), etc.
For a good reference on encodings in PostgreSQL have a look at:
http://postgresql.org/users-lounge/docs/7.1/admin/multibyte.html
You may want to do one thing: before importing a latin1-encoded dump file into unicode-encoded database, insert a line
containing
encoding latin1
at the beginning of the file.
> How can I check which way I compiled my existing version of PG 7.1.3?
Look towards the first lines of config.status file in the directory you put postgresql sources.
