Re: Re: [COMMITTERS] pgsql: Force strings passed to and from plperl to be in UTF8 encoding.
Alex Hunsaker <badalex@gmail.com>
From: Alex Hunsaker <badalex@gmail.com>
To: Amit Khandekar <amit.khandekar@enterprisedb.com>
Cc: Andrew Dunstan <andrew@dunslane.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-10-04T08:34:14Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Force strings passed to and from plperl to be in UTF8 encoding.
- 50d89d422f9c 9.1.0 cited
Attachments
- plperl_verify_utf_u2e_v2.patch (text/x-patch) patch v2
On Mon, Oct 3, 2011 at 23:35, Amit Khandekar <amit.khandekar@enterprisedb.com> wrote: > 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. Consider a latin1 database where utf8_str was a string of ascii characters. Then no conversion would take place and ret == utf8_str but the string would be verified by pg_do_encdoing_conversion() and verified again by your added check :-). >> 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 ? I went ahead and added one in the attached based upon your example. Look ok to you? BTW thanks for the patch! [ side note ] I still think we should not be doing any conversion in the SQL_ASCII case but this slimmed down patch should be less controversial.