Re: invalid UTF-8 via pl/perl

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Hannu Krosing <hannu(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: invalid UTF-8 via pl/perl
Date: 2010-01-04 14:44:53
Message-ID: 4B41FEE5.6060909@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>> andrew=# select 'a' || invalid_utf_seq() || 'b';
>> ERROR: invalid byte sequence for encoding "UTF8": 0xd0
>> HINT: This error can also happen if the byte sequence does not
>> match the encoding expected by the server, which is controlled by
>> "client_encoding".
>> CONTEXT: PL/Perl function "invalid_utf_seq"
>>
>
>
>> That hint seems rather misleading. I'm not sure what we can do about it
>> though. If we set the noError param on pg_verifymbstr() we would miss
>> the error message that actually identified the bad data, so that doesn't
>> seem like a good plan.
>>
>
> Yeah, we want the detailed error info. The problem is that the hint is
> targeted to the case where we are checking data coming from the client.
> We could add another parameter to pg_verifymbstr to indicate the
> context, perhaps. I'm not sure how to do it exactly --- just a bool
> that suppresses the hint, or do we want to make a provision for some
> other hint or detail message?
>
>
>

This is a mess. It affects four or five levels of visible functions that
are called in about 18 files.

How about we just change the hint so it also refers to the possibility
that the data comes from a PL? That would save lots of trouble.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2010-01-04 14:50:21 Re: pgsql: When estimating the selectivity of an inequality "column >
Previous Message Mark Cave-Ayland 2010-01-04 13:51:15 Re: Add subdirectory support for DATA/DOCS with PGXS