On Feb 11, 2011, at 3:58 PM, Alex Hunsaker wrote: > You mean... we have been talking past each other this whole time?
Well, since my second post, I think. I was wrong in the first one. > Olegs case _was_ a utf8 database. > From his original bug: > >>> Hi there, below is the problem, which I don't have when running in shell. >>> The database is in UTF-8 encoding. Ah. Stupid of me not to have seen that part. > Thats why I have been fighting the notion that he can finally get rid > of the utf8::decode(). The utf8::decode() _before_ uri_unescape() was > wrong, it "fixed" his problem but that was really a bug. The > utf8::decode() after uri_unescape() is the right answer. And he will > still need that pre and post patch. Right. >> * And your PL/Perl functions expect arguments that are byte soup >> * Once you upgrade to 9.1 they won't be >> * So you'll need to encode them. > > Yeah, I think we all agree it should be mentioned in the incompatible > section of the release notes. :-) Right, loud and clear. And the same for values returned from PL/Perl functions, right? They will no longer be returned as binary soup if you return a decoded value. I bet that's not at all common, though. 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
