Skip site navigation (1) Skip section navigation (2)

Re: 9.1 plperlu bug with null rows in trigger hash

From: Alexey Klyukin <alexk(at)commandprompt(dot)com>
To: Alex Hunsaker <badalex(at)gmail(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org, Greg Sabino Mullane <greg(at)endpoint(dot)com>
Subject: Re: 9.1 plperlu bug with null rows in trigger hash
Date: 2011-05-27 20:43:54
Message-ID: B85C3400-0878-4432-B92F-581C5E61FD31@commandprompt.com (view raw or flat)
Thread:
Lists: pgsql-bugs
On May 27, 2011, at 7:14 PM, Alex Hunsaker wrote:

> 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.

Yeah, per the link above the problem is evident and after a little testing
I think your patch fixed the problem. Thank you for tracking down this!

> 
> 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.

+1.

--
Alexey Klyukin
The PostgreSQL Company - Command Prompt, Inc.





In response to

pgsql-bugs by date

Next:From: Tom LaneDate: 2011-05-28 02:04:15
Subject: Re: BUG #6044: Access violation on XML decl with standalone
Previous:From: Christopher DillardDate: 2011-05-27 20:02:04
Subject: BUG #6044: Access violation on XML decl with standalone

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group