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 |
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 |