Re: arrays as pl/perl input arguments [PATCH]

On 02/03/2011 01:01 PM, Tim Bunce wrote:
>
> Imagine that PL/Perl could handle named arguments:
>
>      CREATE FUNCTION join_list( separator text, list array ) AS $$
>          return join( $separator, @$list );
>      $$ LANGUAGE plperl;
>
> The $list variable, magically created by PL/Perl, could be the array
> reference created by your code, without altering the contents of @_.


I think that's getting way too subtle, and it would probably violate the 
POLA. If we implement named arguments I would expect $list to be the 
same as $_[0]



>
>
>>> - Every existing plperl function that takes arrays is going to get
>>>   slower due to the overhead of parsing the string and allocating the
>>>   array and all its elements.
>> Well, per my understanding of Alex changes, the string parsing is not invoked
>> unless requested by referencing the array in a string context. Normally, onle
>> plperl_ref_from_pg_array will be invoked every time the function is called
>> with an array argument, which would take little time to convert the PostgreSQL
>> internal array representation (not a string) to the perl references, but that's
>> no different from what is already done with composite type arguments, which
>> are converted to perl hash references on every corresponding function call.
> I'd missed that it was using the internal array representation (obvious
> in hindsight) but there's still a significant cost in allocating the SVs
> that won't be used by existing code.  Though I agree it's of the same
> order as for composite types.
>

Well, the question seems to be whether or not it's a reasonable price to 
pay. On the whole I'm inclined to think it is, especially when it can be 
avoided by updating your code, which will be a saving in fragility and 
complexity as well.

cheers

andrew