Re: invalidly encoded strings

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: invalidly encoded strings
Дата
Msg-id 46E42ADF.7050007@dunslane.net
обсуждение исходный текст
Ответ на Re: invalidly encoded strings  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: invalidly encoded strings  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: invalidly encoded strings  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers

Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>   
>> Is that going to cover data coming in via COPY? and parameters for 
>> prepared statements?
>>     
>
> Those should be checked already --- if not, the right fix is still to
> fix it there, not in per-datatype code.  I think we are OK though,
> eg see "need_transcoding" logic in copy.c.
>   


Well, a little experimentation shows that we currently are not OK:

in foo.data:
\366\66


utf8test=# \copy xx from foo.data
utf8test=# select encode(t::bytea,'hex') from xx;encode
--------f636
(1 row)

utf8test=# \copy xx to bb.data
utf8test=# \copy xx from bb.data
ERROR:  invalid byte sequence for encoding "UTF8": 0xf636
HINT:  This error can also happen if the byte sequence does not match 
the encoding expected by the server, which is controlled by 
"client_encoding".
CONTEXT:  COPY xx, line 1
utf8test=#


BTW, all the foo_recv functions that call pq_getmsgtext or 
pq_getmsgstring are thereby calling pg_verify_mbstr already (via 
pg_client_to_server). So I am still not 100% convinced that doing the 
same directly in the corresponding foo_in functions is such a bad idea.

cheers

andrew



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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Are we done with sync-commit-defaults-to-off patch?
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: invalidly encoded strings