Re: JDBC to load UTF8@psql to latin1@mysql

From: Emi Lu <emilu(at)encs(dot)concordia(dot)ca>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: JDBC to load UTF8@psql to latin1@mysql
Date: 2012-12-14 20:10:47
Message-ID: 50CB87C7.5070600@encs.concordia.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 12/14/2012 01:37 PM, Emi Lu wrote:
> Hello All,
>>> Meh. That character renders as \310 in your mail, which is not an
>>> assigned code in ISO 8859-1. The numerically corresponding Unicode
>>> value would be U+0090, which is an unspecified control character.
>>
>> Oh, scratch that, apparently I can't do hex/octal arithmetic in my
>> head first thing in the morning. It's really U+00C8 which is perfectly
>> valid. I can't see a reason why that character and only that character
>> would be problematic --- have you done systematic testing to confirm
>> that that's the only should-be-LATIN1 character that fails?
>
> Finally, the problem is resolved:
>
> SHOW VARIABLES LIKE "character\_set\_%";
> +--------------------------+--------+
> | Variable_name | Value |
> +--------------------------+--------+
> | character_set_client | latin1 |
> | character_set_connection | latin1 |
> | character_set_database | latin1 |
> | character_set_filesystem | binary |
> | character_set_results | latin1 |
> | character_set_server | latin1 |
> | character_set_system | utf8 | -- here mysql uses utf8 for
> character_set_system.
Another try is that if I change my client tool encoding set, I do not
even need my java transition. All right, good to learn from this.

Emi

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Joe Van Dyk 2012-12-14 20:11:05 Quickly making a column non-nullable (without a table scan)
Previous Message AI Rumman 2012-12-14 19:58:49 Re: pg_restore error with out of memory