Skip site navigation (1) Skip section navigation (2)

Re: Continuing encoding fun....

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....
Date: 2005-09-08 10:26:08
Message-ID: E7F85A1B5FF8D44C8A1AF6885BC9A0E4AC9F79@ratbert.vale-housing.co.uk (view raw or flat)
Thread:
Lists: pgsql-odbc
 

> -----Original Message-----
> From: pgsql-odbc-owner(at)postgresql(dot)org 
> [mailto:pgsql-odbc-owner(at)postgresql(dot)org] On Behalf Of Marc Herbert
> Sent: 08 September 2005 11:10
> To: pgsql-odbc(at)postgresql(dot)org
> Subject: Re: [ODBC] Continuing encoding fun....
> 
> "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk> writes:
> 
> > 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.
> 
> I think one extra layer of confusion is added by the fact that POSIX
> defines the type wchar_t as "the abstract/platform-dependent
> character", W just meaning here: "W like Wide enough", whereas
> Microsoft defines WCHAR as: "W like Unicode".  Microsoft's abstract
> character being "TCHAR".
> 
> Am I right here?

That certainly wouldn't help matters. We already have ucs2<->utf-8
conversion in various places to deal with *nix/win32 differences -
trying to properly munge other encodings into those correctly wouldn't
be fun!

As I said though - there are other advantages to having a non-Unicode
driver (like, BDE won't barf for example), so why go to all the hassle,
when we can just advise the non-Unicode folks to use the ANSI driver?

Regards, Dave.

pgsql-odbc by date

Next:From: Merlin MoncureDate: 2005-09-08 12:17:15
Subject: Re: Application bottlenecks
Previous:From: Marc HerbertDate: 2005-09-08 10:09:47
Subject: Re: Continuing encoding fun....

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group