On Fri, Aug 19, 2005 at 10:35:28AM +0200, Andreas Pflug wrote:
> Ben Trewern wrote:
> >I'd like to make a few points on this issue.
> >
> >2. If you do have data in SQL_ASCII the old ODBC driver worked, PgAdmin
> >III works, Delphi and zeoslib works, I understand why there may be a
> >problem but is it not possible to make the new 8.x work?
> >
> >
> >4. I'd like to disagree with your "DO NOT USE ASCII FOR NON-ASCII DATA" as
> >if you read any of Tom Lanes many messages on the subject. Here's a quote:
> >
> >"The SQL_ASCII setting isn't an
> >encoding, really; it's a declaration of ignorance. In this setting
> >the server will just store and regurgitate whatever character strings
> >you send it. This will work fine, more or less, if all your clients
> >use exactly the same encoding and you don't care about functions like
> >upper()/lower()"
If SQL_ASCII is/was equivalent to "ignoring encoding", then it
looks/looked pretty misnamed! For instance if someone wants some UTF16
from/to ASCII then some conversion is definitely needed and
ASCII==ignorance is then a bug.
Encoding ignorance should rather be called SQL_BINARY. A BINARY setting
for strings makes sense, just like when transfering text files using
FTP: you just don't trust FTP for encodings and use it like a
filesystem. BINARY just means that: "don't mess-up with encodings and
let something else deal with the issue".
Of course you cannot then use upper() or whatever if you don't want to
reveal the encoding you use...
> Mind the *if*. You'll always create mess when mixing drivers/apps.
I guess some people knew what they did and simply did not mixed
driver/apps, or in a way they mastered and that worked.
> Ignoring proper encodings is always non-standard,
> so don't expect drivers to support it, and ask for support.
Well while reading at the complaints it seems this BINARY mode was
there before (by "accident"?), even if misnamed... so the BINARY mode
recently disappeared? No surprise some people become angry :-)
> Server encoding is for fixing this issue, and all drivers are obeying
> this. So if you want a guarantee to have a working configuration, DO NOT
> USE ASCII FOR NON-ASCII DATA.
Looks like people fixed issues by themselves before, and Postgres
recent fixing does not interact nicely with theirs?
PS: BTW "unicode" is not one encoding but many different ones.
