[postgis-devel] Re: [Fwd: PostGIS : shp2pgsql i18n patch.]

[IIDA Tetsushi]

> Can you tell us more about this necessity ?
> Is there a case in which a post-processing lets you store
> the data in a postgresql database with no UNICODE support ?

It is unnecessary when often thinking.

The environment for which Japanese was able to be used by the
 EUC-JP code without the UNICODE support when it was before
 PostgreSQL7.1 was able to be made. However, the UNICODE
 support might not have been able to be removed since 7.2.
The situation about which I worried  doesn't occur because PostGIS
 is correspondence since PostgreSQL7.2.

> Consider it as an alpha feature, and only use for testing.
> Tetsushi, please report any problem you might encounter with this.

It tries on this weekend.

Thank you.

--
IIDA Tetsushi
(mailto : Iida_Tetsushi at oi.nu)


----- Original Message ----- 
From: <strk at refractions.net>
To: "IIDA Tetsushi" <hogepiyo at nifty.com>
Cc: <postgis-devel at postgis.refractions.net>; "Jeff Lounsbury" 
<jeffloun at refractions.net>; "Paul Ramsey" <paul at refractions.net>
Sent: Thursday, January 13, 2005 1:16 AM
Subject: Re: [Fwd: PostGIS : shp2pgsql i18n patch.]


> On Thu, Jan 13, 2005 at 12:21:11AM +0900, IIDA Tetsushi wrote:
>> >Tetsushi, with help of some fine postgresql guys I finally
>> >understood the problem and your proposed solution.
>>
>> Thank you.
>>
>> >1) Shouldn't we always produce UTF-8 encoding in output
>> >   in the presence of a -W switch ?
>> >
>> >2) Shouldn't we report intended encoding in the output
>> >   by mean of a SET CLIENT_ENCODING to 'UTF' ?
>> >
>> >Using these two steps we'll be able to use the produced .sql
>> >as input for databases of whatever encoding, with the postgres
>> >server performing the final conversion. Would your nkf step
>> >be useless then ?
>>
>> Yes. That's right in general.
>> I think that the method of surely outputting by UTF-8 is not bad.
>> But, when specification of a character code is included in the output
>> of a program, and the necessity for post-processing comes out,
>> it is trouble somewhat.
>
> Can you tell us more about this necessity ?
> Is there a case in which a post-processing lets you store
> the data in a postgresql database with no UNICODE support ?
>
> --strk;
>
>>
>> The reasons why I did not use UTF8 for an external code ...
>>
>> 1) This patch was worn for the offer of the workaround of
>>   the problem be happening now.
>>   There was no intention to change operation on externals of the
>>   program from the present one greatly.
>>
>> 2) I wanted to avoid showing the user the character-code for internal
>>   processing directly(*1).
>>
>> 3) Since it does not know whether PostgreSQL is compiled so
>>   that UNICODE can be used. (*2)
>>
>> 4) Because UNIX users in the sphere of multibyte-character are
>>  accustomed to the character-code conversion program :-)
>>
>> Neither is so serious reasons.
>>
>> (*1) UTF8 is not so used as an external code in Japan for various 
>> reasons.
>> (*2) I think that such an environment has decreased considerably 
>> recently.
>>
>> --
>> IIDA Tetsushi
>> (mailto : Iida_Tetsushi at oi.nu)
>>
>>