Hackers,
With regard to this (very welcome) commit:
> commit 50d89d422f9c68a52a6964e5468e8eb4f90b1d95
> Author: Andrew Dunstan <and...@dunslane.net>
> Date: Sun Feb 6 17:29:26 2011 -0500
>
> Force strings passed to and from plperl to be in UTF8 encoding.
>
> String are converted to UTF8 on the way into perl and to the
> database encoding on the way back. This avoids a number of
> observed anomalies, and ensures Perl a consistent view of the
> world.
>
> Some minor code cleanups are also accomplished.
>
> Alex Hunsaker, reviewed by Andy Colson.
I just want to emphasize that this needs to be highlighted as a compatibility
change in the release notes. As an example, I currently have this code in PGXN
to process a TEXT param to a function:
my $dist_meta = JSON::XS->new->utf8->decode(shift);
After I upgrade to 9.0, I will have to change that to:
my $dist_meta = JSON::XS->new->utf8(0)->decode(shift);
The upshot is that in those cases where the raw bytes are what's actually
wanted, users will have to modify their functions to turn off the utf8 flag.
This probably won't be that common, but Oleg, for example, will need to convert
his fixed function from:
> CREATE OR REPLACE FUNCTION url_decode(Vkw varchar) RETURNS varchar AS $$
> use strict;
> use URI::Escape;
> utf8::decode($_[0]);
> return uri_unescape($_[0]); $$ LANGUAGE plperlu;
To:
> CREATE OR REPLACE FUNCTION url_decode(Vkw varchar) RETURNS varchar AS $$
> use strict;
> use URI::Escape;
> return uri_unescape($_[0]); $$ LANGUAGE plperlu;
So this needs to be highlighted in the release notes: If a PL/Perl function is
currently relying on a parameter passed in bytes, it will need to be modified
to deal with utf8 strings, instead.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
