From: | Alex Hunsaker <badalex(at)gmail(dot)com> |
---|---|
To: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Careful PL/Perl Release Not Required |
Date: | 2011-02-11 23:58:37 |
Message-ID: | AANLkTinQvn6K8=jAqoUqCtXcRp9F1vx2de=V_FA09V8Z@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 11, 2011 at 16:42, David E. Wheeler <david(at)kineticode(dot)com> wrote:
> On Feb 11, 2011, at 12:57 PM, Alex Hunsaker wrote:
>
>> Yay! 1
>
> Yes, this is all good. But it still seems to me that:
>
> * If your database is neither utf-8 no sql_ascii
You mean... we have been talking past each other this whole time?
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.
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.
> * 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. :-)
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Farina | 2011-02-11 23:58:59 | Re: Replication server timeout patch |
Previous Message | David E. Wheeler | 2011-02-11 23:42:40 | Re: Careful PL/Perl Release Not Required |