Looks good to me.It seems we all seem to think that client_encoding should be set to UNICODE in all cases for unicode builds and SQL_ASCII for others, therefore I've backed out the previous changes and implemented this behaviour instead.
I've changed libpq handling so utf-8 is correctly converted to utf-16. I believe encoding is now handled correctly for unicode builds. A current win32 build is uploaded to snake.pgadmin.org.
Client encoding setting might still be useful for non-unicode builds, if we want to support them at all. The list of selectable client encodings would have to be restricted to 8-bit/char codes.
Actually, I'd prefer to recommend unicode-builds as *the* one and only solution for multi-encoding environments, leaving the non-unicode build pinned to sql_ascii.
Regards, Andreas
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
