On May 27, 2011, at 7:14 PM, Alex Hunsaker wrote: > On Mon, May 23, 2011 at 20:08, Greg Sabino Mullane <g...@endpoint.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 <alvhe...@alvh.no-ip.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. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
