Re: arrays as pl/perl input arguments [PATCH] - Mailing list pgsql-hackers

From Alex Hunsaker
Subject Re: arrays as pl/perl input arguments [PATCH]
Date
Msg-id AANLkTi=ih1Ehy3nUTf3zTqkxZkENmxZgyAyETnrozDXy@mail.gmail.com
Whole thread Raw
In response to Re: arrays as pl/perl input arguments [PATCH]  (Alexey Klyukin <alexk@commandprompt.com>)
Responses Re: arrays as pl/perl input arguments [PATCH]  (Alex Hunsaker <badalex@gmail.com>)
Re: arrays as pl/perl input arguments [PATCH]  (Alex Hunsaker <badalex@gmail.com>)
List pgsql-hackers
On Tue, Feb 8, 2011 at 08:18, Alexey Klyukin <alexk@commandprompt.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 ;)).


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Extensions versus pg_upgrade
Next
From: Robert Haas
Date:
Subject: Re: Extensions versus pg_upgrade