On 02/03/2011 08:29 PM, Alex Hunsaker wrote:
On Mon, Jan 31, 2011 at 01:34, Alexey Klyukin<al...@commandprompt.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
