Michael Fuhr wrote:
>In the latest HEAD, a PL/Perl function that returns a list value
>instead of a reference causes a segmentation fault:
>
>CREATE FUNCTION foo() RETURNS integer[] AS $$
>return (1, 2, 3, 4);
>$$ LANGUAGE plperl;
>
>SELECT foo();
>server closed the connection unexpectedly
>
>Here's the stack trace:
>
>#0 0xfed45bcc in plperl_call_handler (fcinfo=0xffbfe230) at plperl.c:1031
>#1 0x0010e7d4 in ExecMakeFunctionResult (fcache=0x44af00, econtext=0x44ae58,
> isNull=0x44b470 "\177~\177\177\177\177\177\177", isDone=0x44b4d8) at execQual.c:1031
>#2 0x001122b0 in ExecProject (projInfo=0x44af00, isDone=0x44ae58) at execQual.c:3607
>
>
Patch below fixes the SEGV, and you will see instead:
andrew=# select foo();
ERROR: array value must start with "{" or dimension information
which might not immediately point you to the source of the error :-( ,
but is certainly better than a SEGV.
Note that all plperl functions are called in scalar context, and it is
always wrong to return a list (as opposed to a listref). In fact, the
value received might surprise you even if it worked (it would be the
value of the last member of the list).
cheers
andrew
Index: plperl.c
===================================================================
RCS file: /projects/cvsroot/pgsql/src/pl/plperl/plperl.c,v
retrieving revision 1.85
diff -c -r1.85 plperl.c
*** plperl.c 12 Jul 2005 01:16:21 -0000 1.85
--- plperl.c 12 Jul 2005 18:52:54 -0000
***************
*** 1021,1027 **** char *val;
! if (prodesc->fn_retisarray && SvTYPE(SvRV(perlret)) == SVt_PVAV) { array_ret =
plperl_convert_to_pg_array(perlret); SvREFCNT_dec(perlret);
--- 1021,1028 ---- char *val;
! if (prodesc->fn_retisarray && SvROK(perlret) &&
! SvTYPE(SvRV(perlret)) == SVt_PVAV) { array_ret =
plperl_convert_to_pg_array(perlret); SvREFCNT_dec(perlret);