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

From Alexey Klyukin
Subject Re: arrays as pl/perl input arguments [PATCH]
Date
Msg-id D3BE6E45-969D-43E0-85B7-8DC3663D807F@commandprompt.com
Whole thread Raw
In response to Re: arrays as pl/perl input arguments [PATCH]  (Alex Hunsaker <badalex@gmail.com>)
Responses Re: arrays as pl/perl input arguments [PATCH]  (Alex Hunsaker <badalex@gmail.com>)
List pgsql-hackers
On Feb 9, 2011, at 3:44 AM, Alex Hunsaker wrote:

>
> So the merge while not exactly trivial was fairly simple. However it
> would be great if you could give it another look over.
>
> Find attached v7 changes include:
> - rebased against HEAD
> - fix potential use of uninitialized dims[cur_depth]
> - took out accidental (broken) hack to try and support composite types
> in ::encode_array_literal (added in v4 or something)
> - make_array_ref() now uses plperl_hash_from_datum() for composite
> types instead of its own hand rolled version
> - get_perl_array_ref() now grabs the 'array' directly instead of
> through the magic interface for simplicity
> - moved added static declarations to the "bottom" instead of being
> half on top and half on bottom
> <pg_to_perl_arrays_v7.patch.gz>

Thank you very much, the new patch applies cleanly and passes all tests on my
system. The new get_perl_array_ref seems to be much more clear to me, than the
prev. magic call.

What was actually broken in encode_array_literal support of composite types
(it converted perl hashes to the literal composite-type constants, expanding
nested arrays along the way) ? I think it would be a useful extension of the
existing encode_array_literal.

/A

--
Alexey Klyukin
The PostgreSQL Company - Command Prompt, Inc.






pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: SSI patch version 14
Next
From: Markus Wanner
Date:
Subject: Re: SSI patch version 14