Re: invalid UTF-8 via pl/perl
От | Andrew Dunstan |
---|---|
Тема | Re: invalid UTF-8 via pl/perl |
Дата | |
Msg-id | 4B412AF8.8070700@dunslane.net обсуждение исходный текст |
Ответ на | Re: invalid UTF-8 via pl/perl (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: invalid UTF-8 via pl/perl
|
Список | pgsql-hackers |
Tom Lane wrote: > Andrew Dunstan <andrew@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
В списке pgsql-hackers по дате отправления: