|From:||"Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>|
|To:||"Marc Herbert" <Marc(dot)Herbert(at)emicnetworks(dot)com>,<pgsql-odbc(at)postgresql(dot)org>|
|Subject:||Re: Continuing encoding fun....|
|Views:||Raw Message | Whole Thread | Download mbox|
> -----Original Message-----
> From: pgsql-odbc-owner(at)postgresql(dot)org
> [mailto:pgsql-odbc-owner(at)postgresql(dot)org] On Behalf Of Marc Herbert
> Sent: 07 September 2005 19:16
> To: pgsql-odbc(at)postgresql(dot)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
> 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.
|Next Message||Marc Herbert||2005-09-08 10:09:47||Re: Continuing encoding fun....|
|Previous Message||Dave Page||2005-09-08 07:34:44||Re: changed behavior in libpq odbc driver|