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

In response to

Responses

Browse pgsql-hackers by date

  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