Re: Usind database with encoding UNICODE and vovel

Dave Page wrote:
>
>
>
>>-----Original Message-----
>>From: Andreas Pflug [mailto:pgadmin(at)pse-consulting(dot)de]
>>Sent: 03 August 2005 09:28
>>To: Josef Springer
>>Cc: pgsql-odbc(at)postgresql(dot)org; Dave Page
>>Subject: Re: [ODBC] Usind database with encoding UNICODE and vovel
>>
>>Josef Springer wrote:
>>
>>>Hi anybody,
>>>
>>>Encironment: Win2k, german locale, PostgreSQL database with UNICODE
>>>encoding, using via ODBC
>>> Client encoding UNICODE.
>>>
>>>I can read strings containing vovels without problems, But writing
>>>strings containing vovels does not work !
>>>Can anybody assist ?
>>
>>I've been posting a patch earlier this year (January) because
>>I had the
>>same problem on Unicode databases. But this is not the
>>ultimate patch;
>>it will create data errors with non-unicode databases (e.g.
>>Latin-1).
>
>
> OK, well as you know Andreas, my unicode/locale etc. experience is
> pretty much limited to what I've learnt from you and Hiroshi Saito on
> pgAdmin, however, I'm on a roll fixing bugs in psqlODBC at the moment,
> so let's try to sort this :-)

Sadly I don't even have the time to follow this threas thorougly.
IMHO the current pgadmin behaviour should be workable for all situations
(unless data isn't really stored in the encoding as the server encoding
states):

Client encoding is set to UNICODE automatically for all server encodings
excluding SQL_ASCII and MULE_INTERNAL, because for all other encodings
proper conversions exist. For SQL_ASCII and MULE_INTERNAL these are used
as client encoding too, hoping the app knows what to do.

In case the server encoding is wrong, the client will have to have to
play with client encoding itself. In this case, the driver shouldn't try
to do conversions itself, but leave as much as possible to the client.

Regards,
Andreas