Re: arrays as pl/perl input arguments [PATCH]

From: Alex Hunsaker <badalex(at)gmail(dot)com>
To: Alexey Klyukin <alexk(at)commandprompt(dot)com>
Cc: "David E(dot) Wheeler" <david(at)kineticode(dot)com>, pgsql-hackers(at)postgresql(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: arrays as pl/perl input arguments [PATCH]
Date: 2011-02-08 17:33:37
Message-ID: AANLkTi=ih1Ehy3nUTf3zTqkxZkENmxZgyAyETnrozDXy@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

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