On Tue, Feb 8, 2011 at 08:18, Alexey Klyukin <alexk(at)commandprompt(dot)com> wrote:
>
> On Feb 6, 2011, at 9:43 AM, Alex Hunsaker wrote:

>> So here is a v6
>> ....
>> Comments?
>
> Thanks, looks great to me. It passes all the tests on my OS X system. I wonder
> what's the purpose of the amagic_call in get_perl_array_ref, instead of
> calling newRV_noinc on the target SV * ?

Well, you can't AV *av = (AV *)SvRV(sv); And the SV * amagic_call
returns is already a reference, so the newRV_noinc() would be
redundant no? It occurs to me instead of doing the amagic_call we
could just call the to_array method directly using perl_call_pv().
That would look more normal and less magic-- thats probably a good
thing?


> Also, in array_to_datum (line 1050), if get_perl_array_ref returns NULL for
> the first element of the corresponding dimension, but non-NULL for the second
> one - it would use uninitialized dims[cur_depth] value in comparison (which,
> although, would probably lead to the desired comparison result).

Good catch, will fix. All of those checks should be outside of the while loop.

While Im at it Ill also rebase against HEAD (im sure there will be
some conflicts with that other plperl patch that just went in ;)).

In response to

• Re: arrays as pl/perl input arguments [PATCH] at 2011-02-08 15:18:22 from Alexey Klyukin

Responses

• Re: arrays as pl/perl input arguments [PATCH] at 2011-02-08 18:31:25 from Alex Hunsaker
• Re: arrays as pl/perl input arguments [PATCH] at 2011-02-09 01:44:00 from Alex Hunsaker

pgsql-hackers by date

Next:	From: Robert Haas	Date: 2011-02-08 17:36:54
	Subject: Re: Extensions versus pg_upgrade
Previous:	From: Tom Lane	Date: 2011-02-08 17:30:47
	Subject: Re: Extensions versus pg_upgrade