------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
http://www.exim.org/bugzilla/show_bug.cgi?id=508
Summary: PostgreSQL client_encoding broken
Product: Exim
Version: 4.67
Platform: Macintosh
URL: http://www.exim.org/mail-archives/exim-dev/2007-
May/msg00027.html
OS/Version: All
Status: NEW
Keywords: work:tiny
Severity: bug
Priority: medium
Component: General execution
AssignedTo: ph10@???
ReportedBy: casey@???
QAContact: exim-dev@???
(sorry for the extra post to exim-dev - didn't notice there's a bugzilla now
before sending that)
Exim Changelog:
> PH/19 Added PQsetClientEncoding(conn, "SQL_ASCII") to the pgsql code module.
> This is apparently needed in addition to the PH/07 change above to avoid
> any possible encoding problems.
SQL_ASCII encoding isn't an encoding at all - rather, it's the lack
thereof. If you have a database initialized with the SQL_ASCII encoding
(sadly the default in <=7.4 [1]), then no encoding checks are done on data
coming into the database. You can throw whatever you want in, but then,
you rely on your client software knowing the encoding of the data it's
pulling out as it could be in any old encoding and you don't really have
any idea which one. So, if you use a single database for numerous
applications, some of which are UTF-8, others which are ISO-8859-1, and
perhaps another that's BIG5, and you want them all to be able to access
and modify subsets of the same data, you're asking for trouble as you'll
run into encoding issues constantly. It also means you can't cleanly
export your database data to any other form that expects a single encoding
- a single byte in an incompatible encoding will throw a monkey wrench
into things.
The solution is to pick an appropriate encoding and go with it. This is
the default configuration if you don't explicitely specify at database
initialization time and your system encoding is set up as of PostgreSQL
8.0 [2]. In my case, as I need to support several languages and
applications within one database, that choice was UTF-8. When I encounter
an application, such as Exim <4.67, that doesn't talk in UTF-8 natively
but needs to enter noncompatible characters in another encoding, I address
that with "alter role blah set client_encoding = 'ISO-8859-1'" or
whatever, which causes PostgreSQL to translate between the client's
encoding and database encoding automatically [3]. This does the same
thing as PQSetClientEncoding, but it does it at connection time, without
executing a set statement. This means that when the application does
finish the connection and sends a set statement, it overrides any setting
I have placed in the database.
I wouldn't mind Exim calling PQSetClientEncoding if it actually set the
encoding to what it internally supports (which would make it "just work"
on non-ISO-8859-1/SQL_ANSII databases such as mine without an
administrator override), however as it overrides the database settings I'm
not sure that it's such a good idea to call it unconditionally without an
option to do so.
[1]
http://www.postgresql.org/docs/7.4/static/app-initdb.html
[2]
http://www.postgresql.org/docs/8.0/static/app-initdb.html
[3]
http://www.postgresql.org/docs/current/static/multibyte.html#AEN24138
--
Configure bugmail:
http://www.exim.org/bugzilla/userprefs.cgi?tab=email
