Re: Unicode support

LATIN1 and UCS have one common point by design:
0x00 - 0xFF are equal numbers, so the SQL_ASCII
ignorance means, that LATIN1 characters won't get changed!

So, this means, that:
0xE4 in ISO-8859-1 is the same as
0x00E4 in UCS-2. Just the number of needed bytes change.

Reference: "man 7 unicode"

Marko Ristola

Dave Page wrote:

> Hi Anoop and anyone else who might be interested,
>
> I've been thinking about how the Unicode support might be improved to
> allow the old 07.xx non-unicode style behaviour to work for those that
> need it. At them moment, when we connect using on of the wide connect
> functions, the CC->unicode flag is set to true. This only affects a few
> options, such as pgtype_to_concise_type()'s mapping of PG types to SQL
> types.
>
> It seems to me that perhaps we should set CC->unicode = 1, only upon
> connection to a Unicode database. Anything else, we leave it set to 0 so
> that it always maps varchars etc to ANSI types, and handles other
> encodings in single byte or non-unicode multibyte mode (which worked
> fine in 07.xx where those encodings where appropriate, such as SJIS in
> Japan). This should also help BDE based apps, which further research has
> shown me are broken with Unicode columns in SQL Server and Oracle as
> well as PostgreSQL (search unicode + BDE on Google Groups for more).
>
> Am I seeing a possible improvement where in fact there isn't one, or
> missing some obvious downside?
>
> Regards, Dave.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>  


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster