Re: invalid UTF-8 via pl/perl - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: invalid UTF-8 via pl/perl
Date
Msg-id 4B3FCDC0.1000902@dunslane.net
Whole thread Raw
In response to invalid UTF-8 via pl/perl  (Hannu Krosing <hannu@2ndquadrant.com>)
Responses Re: invalid UTF-8 via pl/perl  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers

Hannu Krosing wrote:

[plperl can return data that is not valid in the server encoding and it 
is not caught]

> This results in a table, which has invalid utf sequence in it and
> consequently does not pass dump/load
>
> What would be the best place to fix this ?
>
> Should there be checks in all text types ? 
> (probably too expensive)
>   

The plperl code has no type-specific checks, and in any case limiting it 
to "text" types would defeat third party and contrib types of which it 
knows nothing (think citext). We should check all strings returned by 
plperl.
> Or should pl/perl check it's return values for compliance with
> server_encoding ?
>   

I think the plperl glue code should check returned strings using 
pg_verifymbstr().

> Or should postgresql itself check that pl-s return what they promise to
> return ?
>
>   


There is no central place for it to check. The pl glue code is the right 
place, I think.

cheers

andrew




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: psql tab completion for DO blocks
Next
From: Peter Eisentraut
Date:
Subject: Re: ssize_t vs win64