From: | Alex Hunsaker <badalex(at)gmail(dot)com> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Cc: | Greg Sabino Mullane <greg(at)endpoint(dot)com> |
Subject: | Re: 9.1 plperlu bug with null rows in trigger hash |
Date: | 2011-05-27 16:14:25 |
Message-ID: | BANLkTik=9PjnFSB79EFJ=0z6m7LvK3094Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Mon, May 23, 2011 at 20:08, Greg Sabino Mullane <greg(at)endpoint(dot)com> wrote:
> On Mon, May 23, 2011 at 05:04:40PM -0600, Alex Hunsaker wrote:
> ...
>> Greg, can you confirm the attached fixes it for you?
>
> Yes, seems to have done the job, thank you.
Thanks for testing!
[ Does a little dance to try and attract a -commiter ]
This was broken as part of:
commit 87bb2ade2ce646083f39d5ab3e3307490211ad04
Author: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Date: Thu Feb 17 22:11:50 2011 -0300
Convert Postgres arrays to Perl arrays on PL/perl input arguments
More generally, arrays are turned in Perl array references, and row and
composite types are turned into Perl hash references. This is done
recursively, in a way that's natural to every Perl programmer.
To avoid a backwards compatibility hit, the string representation of
each structure is also available if the function requests it.
Authors: Alexey Klyukin and Alex Hunsaker.
Some code cleanups by me.
Which also means it only breaks HEAD/9.1 (I did test and review 9.0 and down.)
Per http://search.cpan.org/~jesse/perl-5.14.0/pod/perlguts.pod#AVs,_HVs_and_undefined_values,
we do not want to use &PL_sv_undef for undef values in hashes and
arrays. I (inadvertently) broke this in the above commit. As perldoc
mentions &PL_sv_undef seems like the intuitive thing to use. But its
wrong in certain cases.
We have 6 other uses of &PL_sv_undef, 2 &PL_sv_no and 1 &PL_sv_yes.
These are all ok as none of them use the HV/AV store interface.
I elected _not_ to add any regression tests. (If we forget about this
in the future, it will likely be in other code paths). Instead I added
comments to the places that used &PL_sv_undef noting that we
explicitly avoid it on purpose.
From | Date | Subject | |
---|---|---|---|
Next Message | Mathew Samuel | 2011-05-27 18:26:34 | UTC4115FATAL: the database system is in recovery mode |
Previous Message | Heikki Linnakangas | 2011-05-27 14:18:11 | Re: BUG #6043: Compilation PLpgsql Succesful but execution bad |