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