Re: invalid UTF-8 via pl/perl

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Hannu Krosing <hannu(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: invalid UTF-8 via pl/perl
Date: 2010-01-03 14:28:29
Message-ID: 4B40A98D.6000307@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan wrote:
>
>
> Andrew Dunstan wrote:
>>
>> I think the plperl glue code should check returned strings using
>> pg_verifymbstr().
>>
>>
>
> Please test this patch. I think we'd probably want to trap the
> encoding error and issue a customised error message, but this plugs
> all the holes I can see with the possible exception of values inserted
> via SPI calls. I'll check that out.
>
>

I think the attached patch plugs the direct SPI holes as well.

One thing that I am pondering is: how does SPI handle things if the
client encoding and server encoding are not the same? Won't the strings
it passes the parser be interpreted in the client encoding? If so, that
doesn't seem right at all, since these strings come from a server side
call and not from the client at all. It looks to me like the call to
pg_parse_query() in spi.c should possibly be surrounded by code to
temporarily set the client encoding to the server encoding and then
restore it afterwards.

cheers

andrew

Attachment Content-Type Size
perl-utf8-2.patch text/x-patch 3.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-01-03 14:53:41 Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns
Previous Message Tatsuo Ishii 2010-01-03 12:00:33 Re: exec_execute_message crash