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-02 22:50:40 |
Message-ID: | 4B3FCDC0.1000902@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2010-01-02 23:20:48 | Re: ssize_t vs win64 |
Previous Message | Tom Lane | 2010-01-02 22:34:19 | Re: psql tab completion for DO blocks |