From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
---|---|
To: | Alex Hunsaker <badalex(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Careful PL/Perl Release Not Required |
Date: | 2011-02-12 02:02:06 |
Message-ID: | E06422AC-497D-4A3A-9BBA-66699C38FD22@kineticode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Itagaki Takahiro | 2011-02-12 02:15:11 | Re: multiset patch review |
Previous Message | marcin mank | 2011-02-12 01:55:57 | Re: ALTER EXTENSION UPGRADE, v3 |