From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Steve Atkins <steve(at)blighty(dot)com> |
Cc: | Postgres general mailing list <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Need help with quote escaping in exim for postgresql |
Date: | 2006-07-14 02:30:34 |
Message-ID: | 25428.1152844234@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
[ Coming late to the thread... ]
Steve Atkins <steve(at)blighty(dot)com> writes:
> Fortunately all this stuff is MUA-side, not MTA-side, so exim
> should ignore it. SQL_ASCII all the way.
I concur. The recent encoding fixes are for the situation where the
database server believes a multibyte encoding is in use, but the client
code is ignorant of that encoding and either (a) sends invalidly encoded
data or (b) does escaping that mangles multibyte characters.
If your client-side code is encoding agnostic, then using SQL_ASCII
(which is also effectively encoding agnostic) for both client_encoding
and server_encoding will work nicely.
A possibly safer choice is to use LATIN1 (or another single-byte
encoding) instead; this will avoid problems if someone connects to the
database with a client_encoding other than SQL_ASCII and expects data
to be delivered to him in that encoding.
I would *not* recommend using UTF8 if you want to store arbitrary data
without worrying about encoding issues.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Agent M | 2006-07-14 02:49:30 | Re: Timestamp vs timestamptz |
Previous Message | Tom Lane | 2006-07-14 01:25:10 | Re: duplicated values on primary key field on reindex |