From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | edward(at)lijianghy(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: How to disable encoding validation during database restore |
Date: | 2002-08-21 06:06:12 |
Message-ID: | 20020821.150612.44988258.t-ishii@sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Hi Tatsuo Ishii :
>
> Thank you very much for your reply. Somehow I managed to restore the data by
> creating by database in SQL_ASCII encoding. Then I changed the encoding of
> my database into EUC_CN thru "update pg_database set encoding=2". But the
> same problem happened in "vacuum verbose analyze". I went thru the changelog
> and found out that you have add the multibyte validation feature from
> release 7.2 on. Looks like the only way to get around is to patch the
> source.
>
> But I would like to suggest that this feature should be made configurable.
> You know encoding is a such a mess in the Chinese language, the popular
> Chinese input methods actually allow the input of any Chinese character from
> different encodings(e.g., GB2312/GBK, big5), it is difficult to make sure
> that the user always input valid characters unless you validate the insert
> and update clause.
But the encoding validation is made for such cases. It will prevent
the database from INSERT/UPDATE with wrong encoding data. If you
really want to allow input any GB2312/GBK, big5 etc. encoded data to
the database, why don't you simply use SQL_ASCII or some other single
byte encodings? If you mix up GB2312/GBK, big5 in a database you could
not perform sort or any other database operation properly anyway.
--
Tatsuo Ishii
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2002-08-21 06:11:28 | Re: pgstattuple change using SRF |
Previous Message | Tom Lane | 2002-08-21 05:54:36 | Re: pgstattuple change using SRF |