Re: [BUGS] BUG #9210: PostgreSQL string store bug? not enforce check with correct characterSET/encoding

Поиск
Список
Период
Сортировка
От digoal
Тема Re: [BUGS] BUG #9210: PostgreSQL string store bug? not enforce check with correct characterSET/encoding
Дата
Msg-id 7ab78936.17ace.1442e1abb73.Coremail.digoal@126.com
обсуждение исходный текст
Ответ на Re: [BUGS] BUG #9210: PostgreSQL string store bug? not enforce check with correct characterSET/encoding  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
HI,
   Thanks very much.  
    We use dblink or foreign table migrate datas instead pg_dump now resolve the error data load problem.
--
公益是一辈子的事,I'm Digoal,Just Do It.


At 2014-02-14 04:49:08,"Tom Lane" <tgl@sss.pgh.pa.us> wrote: >digoal@126.com writes: >> select t, t::bytea from convert_from('\xeec1', 'sql_ascii') as g(t); >> [ fails to check that string is valid in database encoding ] > >Hm, yeah.  Normal input to the database goes through pg_any_to_server(), >which will apply a validation step if the source encoding is SQL_ASCII >and the destination encoding is something else.  However, pg_convert and >some other places call pg_do_encoding_conversion() directly, and that >function will just quietly do nothing if either encoding is SQL_ASCII. > >The minimum-refactoring solution to this would be to tweak >pg_do_encoding_conversion() so that if the src_encoding is SQL_ASCII but >the dest_encoding isn't, it does pg_verify_mbstr() rather than nothing. > >I'm not sure if this would break anything we need to have work, >though.  Thoughts?  Do we want to back-patch such a change? > > regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: narwhal and PGDLLIMPORT
Следующее
От: Florian Pflug
Дата:
Сообщение: Re: Memory ordering issue in LWLockRelease, WakeupWaiters, WALInsertSlotRelease