invalid UTF-8 via pl/perl
in [PgSql]
|
From: Andrew Dunstan on 3 Jan 2010 18:40 Tom Lane wrote: > Andrew Dunstan <andrew(a)dunslane.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? > > > Or instead of another param we could change the third param to be one of (NO_ERROR, CLIENT_ERROR, SERVER_ERROR) or some such. Or we could just add another verify func. I don't have terribly strong opinions about it. Incidentally, I guess we need to look at plpython and pltcl for similar issues. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Peter Eisentraut on 4 Jan 2010 05:46 On sön, 2010-01-03 at 18:40 -0500, Andrew Dunstan wrote: > Incidentally, I guess we need to look at plpython and pltcl for > similar issues. I confirm that the same issue exists in plpython. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andrew Dunstan on 4 Jan 2010 09:44 Tom Lane wrote: > Andrew Dunstan <andrew(a)dunslane.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 4 Jan 2010 10:11 Andrew Dunstan <andrew(a)dunslane.net> writes: > 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. Maybe just lose the hint altogether. It's not adding that much, and I seem to recall that there have already been complaints about other cases where it's misleading. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
First
|
Prev
|
Pages: 1 2 3 Prev: [HACKERS] invalid UTF-8 via pl/perl Next: Testing with concurrent sessions |