Re: arrays as pl/perl input arguments [PATCH]
От | Alex Hunsaker |
---|---|
Тема | Re: arrays as pl/perl input arguments [PATCH] |
Дата | |
Msg-id | AANLkTimxOze010uT-AGn=nFP7P_w5=DmUpm0xc5PWhWN@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: arrays as pl/perl input arguments [PATCH] (Alexey Klyukin <alexk@commandprompt.com>) |
Ответы |
Re: arrays as pl/perl input arguments [PATCH]
Re: arrays as pl/perl input arguments [PATCH] |
Список | pgsql-hackers |
On Mon, Jan 31, 2011 at 01:34, Alexey Klyukin <alexk@commandprompt.com> wrote: > I've looked at the patch and added a test for arrays exceeding or equal maximum dimensions to check, whether the recursivefunction 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?
В списке pgsql-hackers по дате отправления: