SEO

#1 (**permalink**) 04-16-2008, 01:21 AM

> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org
> [mailto

gsql-odbc-owner@postgresql.org] On Behalf Of Ben Trewern
> Sent: 15 August 2005 13:44
> To: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] Bug or not about ASCII and Multi-Byte
> character set
>
> I'd like to make a few points on this issue.
>
> 1. This problem should be mentioned in the FAQs as largely
> as possible as
> it is difficult to rectify if you have fallen into this trap.

Agreed - I'll do that.

> 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?

Actually, pgAdmin doesn't always work. If you try to insert Japanese
characters into an SQL_ASCII database it errors for example. Try it with
a Unicode database and it's fine.

Also, the old ODBC driver didn't always work either. If you check the
archives, you'll find people complaining of the same problem with the
non-libpq drivers.

> 3. Correct me if I'm wrong but SQL_ASCII is PostgreSQL's
> default encoding.
> If this isn't sorted out then we'll see lots more of these
> messages for
> help.
>
> 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()"

Which is fine - however, as Tom also says:

"If you flip between SQL_ASCII and other settings, on either end,
without
clearly understanding what's happening, you're likely to get very
confused."

Which is pretty much what seems to be happening - ppl are using a
Unicode ODBC driver, and 7bit ascii data that cannot be properly
represented gets converted to '?'. They don't necessarily realise that
apps like Access will usually retrieve data as SQL_C_WCHAR if they can,
thus forcing a conversion to Unicode.

Regards, Dave

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

SEO

Re: Bug or not about ASCII and Multi-Byte character set