Re: invalidly encoded strings

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: invalidly encoded strings
Date: 2007-09-09 17:18:23
Message-ID: 46E42ADF.7050007@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2007-09-09 18:00:35 Re: invalidly encoded strings
Previous Message Andrew Dunstan 2007-09-09 17:03:40 Re: Are we done with sync-commit-defaults-to-off patch?

Browse pgsql-patches by date

  From Date Subject
Next Message Jeff Davis 2007-09-09 18:00:35 Re: invalidly encoded strings
Previous Message Tom Lane 2007-09-09 16:14:00 Re: invalidly encoded strings