On 3 October 2011 22:37, Alex Hunsaker <bada...@gmail.com> wrote: > On Mon, Oct 3, 2011 at 04:20, Amit Khandekar > <amit.khande...@enterprisedb.com> wrote: > >> Is there a plan to commit this issue? I am still seeing this issue on >> PG 9.1 STABLE branch. Attached is a small patch that targets only the >> specific issue in the described testcase : >> >> create or replace function zerob() returns text as $$ return >> "abcd\0efg"; $$ language plperl; >> SELECT zerob(); >> >> The patch does the perl data validation in the function utf_u2e() itself. > > I think thats fine, but as coded it will verify the string twice in > the GetDatabaseEncoding() != PG_UTF8 case (once for > pg_do_encoding_conversion() and again with the added > pg_verify_mbstr_len), which seems a bit wasteful.
WHen GetDatabaseEncoding() != PG_UTF8 case, ret will not be equal to utf8_str, so pg_verify_mbstr_len() will not get called. That's the reason, pg_verify_mbstr_len() is under the ( ret == utf8_str ) condition. > > It might be worth adding a regression test also... I could not find any basic pl/perl tests in the regression serial_schedule. I am not sure if we want to add just this scenario without any basic tests for pl/perl ? > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
