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