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

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

From: Alexey Klyukin <alexk(at)commandprompt(dot)com>
To: Alex Hunsaker <badalex(at)gmail(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 15:18:22
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Feb 6, 2011, at 9:43 AM, Alex Hunsaker wrote:

> On Thu, Feb 3, 2011 at 18:29, Alex Hunsaker <badalex(at)gmail(dot)com> wrote:
>> On Mon, Jan 31, 2011 at 01:34, Alexey Klyukin <alexk(at)commandprompt(dot)com> wrote:
>>> I've looked at the patch and added a test for arrays exceeding or equal maximum dimensions to check, whether the recursive function won't bring surprises there. I've also added check_stack_depth calls to both split_array and plperl_hash_from_tuple. Note that the regression fails currently due to the incorrect error reporting in
>>> PostgreSQL, per
>>> The v5 is attached.
>> One thing I find odd is we allow for nested arrays, but not nested
>> composites.  For example:
> ...
>> On the other end, the same is true when returning. If you try to
>> return a nested composite or array, the child better be a string as it
>> wont let you pass a hash:
> So here is a v6 that does the above. It does so by providing a generic
> plperl_sv_to_datum() function and converting the various places to use
> it. One cool thing is you can now use the composite types or arrays
> passed in (or returned from another spi!) as arguments for
> spi_exec_prepared(). Before you would have to convert the hashes to
> strings. It also provides a real plperl_convert_to_pg_array (now
> plperl_array_to_datum) that can handle composite and other random
> datatypes. This also means we don't have to convert arrays to a string
> representation first. (which removes part of the argument for #5 @
> I have attached a stand alone version of the above so its easier to
> look over. The diffstat is fairly small (ignoring added regression
> tests)
> 1 files changed, 259 insertions(+), 165 deletions(-)
> 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 * ?

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

Alexey Klyukin
The PostgreSQL Company - Command Prompt, Inc.

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2011-02-08 15:21:03
Subject: Re: Extensions support for pg_dump, patch v27
Previous:From: Jan UrbaƄskiDate: 2011-02-08 15:07:53
Subject: Re: postponing some large patches to 9.2

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