On Mon, Jan 31, 2011 at 01:34, Alexey Klyukin <[email protected]> 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. For example:
=> create type foo as (a int[]);
=> create type foofoo as (b foo);
=> create or replace function fa(foofoo[]) returns void as $$
my $foofoo_array = shift;
warn ref $foofoo_array->[0] || 'SCALAR';
warn ref $foofoo_array->[0]->{'b'} || 'SCALAR';
$$ language plperl;
=> select fa(ARRAY[ROW(ROW(ARRAY[1]))]::foofoo[]);
WARNING: HASH at line 3.
CONTEXT: PL/Perl function "fa"
WARNING: SCALAR at line 4.
CONTEXT: PL/Perl function "fa"
Why is foofoo.b a scalar but foofoo is a hash? 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:
=> create type foo as (a int[]);
=> create or replace function foo_in(foo) returns foo as $$ shift; $$
language plperl;
=> create or replace function foo_out() returns foo as $$ return
{'a'=>[1,2,3]}; $$ language plperl;
=> -- this works with the patch because we treat the reference as a string
=> select foo_in('("{1,2,3}")'::foo);
foo_in
-------------
("{1,2,3}")
=> select foo_out();
ERROR: array value must start with "{" or dimension information
CONTEXT: PL/Perl function "foo_out"
STATEMENT: SELECT foo_out();
-- also works as a straight string
=> create or replace function foo_out_str() returns foo as $$ return
{'a'=>'{1,2,3}'}; $$ language plperl;
=> select foo_out_str();
foo_out_str
-------------
("{1,2,3}")
(1 row)
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?
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
