Re: Continuing encoding fun.... - Mailing list pgsql-odbc

From Dave Page
Subject Re: Continuing encoding fun....
Date
Msg-id E7F85A1B5FF8D44C8A1AF6885BC9A0E4AC9F6C@ratbert.vale-housing.co.uk
Whole thread Raw
In response to Continuing encoding fun....  ("Dave Page" <dpage@vale-housing.co.uk>)
List pgsql-odbc

> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org
> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Marc Herbert
> Sent: 07 September 2005 19:16
> To: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] Continuing encoding fun....
>
> In a perfect world there are no "unicode apps",

In my perfect world, everything is one flavour of Unicode, and everyone
can consequently read and write everything with no compatibilty problems
at all. But then I like to retreat to my little fantasy world from time
to time...

>
> However, I have no idea how this theory is far from reality, far from
> the ODBC API, and far from Windows, sorry :-( I just was woken up by
> the "unicode apps" word. I tried to follow the discussions here but
> got lost.

The ODBC API (defined by Microsoft of course) includes a number of *W
functions which are Unicode variants of the ANSI versions with the same
name. The ODBC driver manager maps all ANSI function calls to the
Unicode equivalents if they exist, on the assumption that ASCII chars
will map correctly into Unicode (which they do if they are 7 bit chars).
In theory we could attempt to recode incoming ascii or multibyte
ourselves I guess, but it's not going to be a particularly easy task
(and will mean performance loss), and given that some apps don't play
nicely with Unicode drivers anyway, we might as well kill 2 birds with
one stone and just ship 2 versions of the driver.

Regards, Dave.

pgsql-odbc by date:

Previous
From: Marc Herbert
Date:
Subject: Re: Continuing encoding fun....
Next
From: Marc Herbert
Date:
Subject: Re: Continuing encoding fun....