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

On 02/03/2011 08:29 PM, Alex Hunsaker 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 http://archives.postgresql.org/pgsql-hackers/2011-01/msg02888.php.
>>
>> The v5 is attached.
> One thing I find odd is we allow for nested arrays, but not nested
> composites.

> This is not unique to
> the patch, it how nested composites are handled in general. That is
> if you passed in ROW(ROW()), the first ROW would be a hash while the
> 2nd row would be a scalar.
>
> 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

I think the reason this is so has to do with the history. Composite
support came to plperl about the same time (in the 8.0 cycle, IIRC) that
we were getting more support for nested composites in Postgres, and they
sorta passed like ships in the night.

> Anyone object to fixing the above as part of this patch? That is
> making plperl_(build_tuple_result, modify_tuple, return_next,
> hash_from_tuple) handle array and hash (composite/row) types
> consistently? And _that_ would be to recurse and turn them from/into
> perl objects. Thoughts?
>

I have no objection to making the whole thing work recursively, in
principle, but will it break legacy code?

cheers

andrew