Thread: plperl returning setof foo[]

I have just noticed, somewhat to my chagrin, that while in a plperl
function that returns an array type you can return a perl arrayref, like
this:

    return [qw(a b c)];

if the function returns a setof an array type you cannot do this:

    return_next [qw(a b c)];

Now the plperl docs say:

    Perl can return PostgreSQL arrays as references to Perl arrays. Here
    is an example:

    CREATE OR REPLACE function returns_array()
    RETURNS text[][] AS $$
        return [['a"b','c,d'],['e\\f','g']];
    $$ LANGUAGE plperl;

    select returns_array();

and while it doesn't specifically mention SRFs it doesn't exclude them,
either.

The fix is fairly small (see attached) although I need to check with
some perlguts guru to see if I need to decrement a refcounter here or there.

Nobody has complained about it over the years, so I wonder if it should
be backpatched. It wouldn't change any working behaviour, just remove
the non-working property of some documented behaviour.

cheers

andrew



Index: plperl.c
===================================================================
RCS file: /cvsroot/pgsql/src/pl/plperl/plperl.c,v
retrieving revision 1.150
diff -c -r1.150 plperl.c
*** plperl.c    11 Jun 2009 14:49:14 -0000    1.150
--- plperl.c    12 Sep 2009 16:46:40 -0000
***************
*** 1992,2001 ****
      {
          Datum        ret;
          bool        isNull;

          if (SvOK(sv))
          {
!             char       *val = SvPV(sv, PL_na);

              ret = InputFunctionCall(&prodesc->result_in_func, val,
                                      prodesc->result_typioparam, -1);
--- 1992,2011 ----
      {
          Datum        ret;
          bool        isNull;
+         SV           *array_ret = NULL;

          if (SvOK(sv))
          {
!             char       *val;
!
!             if (prodesc->fn_retisarray && SvROK(sv) &&
!                 SvTYPE(SvRV(sv)) == SVt_PVAV)
!             {
!                 array_ret = plperl_convert_to_pg_array(sv);
!                 sv = array_ret;
!             }
!
!             val = SvPV(sv, PL_na);

              ret = InputFunctionCall(&prodesc->result_in_func, val,
                                      prodesc->result_typioparam, -1);

Andrew Dunstan <andrew@dunslane.net> writes:
> The fix is fairly small (see attached) although I need to check with 
> some perlguts guru to see if I need to decrement a refcounter here or there.

The array_ret variable seems a bit unnecessary, and declared well
outside the appropriate scope if it is necessary.

> Nobody has complained about it over the years, so I wonder if it should 
> be backpatched. It wouldn't change any working behaviour, just remove 
> the non-working property of some documented behaviour.

AFAICT it just fails, so backpatching seems like a bug fix not a
behavioral change.
        regards, tom lane

Tom Lane wrote:
>> Nobody has complained about it over the years, so I wonder if it should 
>> be backpatched. It wouldn't change any working behaviour, just remove 
>> the non-working property of some documented behaviour.
>>     
>
> AFAICT it just fails, so backpatching seems like a bug fix not a
> behavioral change.
>
>             
>   

OK. will fix.

cheers

andrew

At 2009-09-12 13:17:50 -0400, andrew@dunslane.net wrote:
>
> I have just noticed, somewhat to my chagrin, that while in a plperl
> function that returns an array type you can return a perl arrayref,
> like this:
>
>    return [qw(a b c)];
>
> if the function returns a setof an array type you cannot do this:
>
>    return_next [qw(a b c)];

Right. This was an unintentional omission on my part.

> The fix is fairly small (see attached) although I need to check with
> some perlguts guru to see if I need to decrement a refcounter here or
> there.

Slightly simpler patch attached (and tested).

-- ams

Abhijit Menon-Sen wrote:
>> The fix is fairly small (see attached) although I need to check with
>> some perlguts guru to see if I need to decrement a refcounter here or
>> there.
>>     
>
> Slightly simpler patch attached (and tested).
>
>   


Thanks. Committed.

cheers

andrew