From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)surnet(dot)cl> |
Cc: | Oliver Jowett <oliver(at)opencloud(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SQL_ASCII vs. 7-bit ASCII encodings |
Date: | 2005-05-13 13:59:27 |
Message-ID: | 23387.1115992767@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)surnet(dot)cl> writes:
> The problem is that a single application coming from a single
> environment is happy with a 8-bit-unchecked encoding, but as soon as
> they develop a second application using a different environment, which
> uses a different encoding, they start seeing invalid data pop up.
[ shrug... ] The evidence at hand says that many people never get to
that point. For instance, a particular database may never be accessed
through anything except JDBC, and so all the incoming data will be utf8
anyway.
My feeling about it is that we already made significant changes in 8.0
--- it won't default to SQL_ASCII unless your locale is "C", which to me
is a pretty strong indication that you are not very concerned about
encodings. We should wait and see what field experience is like with
that, rather than insisting on anything as anal-retentive as disallowing
8-bit data in SQL_ASCII. Doing that might have technical purity but I
think it will create as many problems as it prevents.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2005-05-13 14:17:10 | Re: SQL_ASCII vs. 7-bit ASCII encodings |
Previous Message | Alvaro Herrera | 2005-05-13 13:48:12 | Re: SQL_ASCII vs. 7-bit ASCII encodings |