From: | Alexey Klyukin <alexk(at)commandprompt(dot)com> |
---|---|
To: | Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net> |
Subject: | Re: arrays as pl/perl input arguments [PATCH] |
Date: | 2011-02-03 12:23:32 |
Message-ID: | B18F9788-32C6-403B-9BD5-8E35695DA0B5@commandprompt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On Feb 2, 2011, at 7:16 PM, Tim Bunce wrote:
> I'm sorry I'm late to this party. I haven't been keeping up with pgsql-hackers.
Better late than never :)
>
> I'd kind'a hoped that this functionality could be tied into extending
> PL/Perl to handle named arguments. That way the perl variables
> corresponding to the named arguments could be given references without
> breaking any code.
Franky I don't see a direct connection between conversion of arrays into array
references and supporting named arguments. Could you, please, show some
examples of how you hoped the functionality could be extended?
>
> Some observations on the current code (based on a quick skim):
>
> - I'd like to see the conversion function exposed as a builtin
> $ref = decode_array_literal("{...}");
In principal, I think that's not hard to built with the functionality provided
by this patch. I see this as an XS function which takes the array string,
calls the array_in to convert it to the array datum, and, finally, calls
plperl_ref_from_pg_array (provided by the patch) to produce the resulting
array reference.
>
> - 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 sting) 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.
>
> - Some of those functions may not use the array at all and some may
> simply pass it on as an argument to another function.
I don't see how it would be good to optimize for the functions that are
declared to get the array but in fact do nothing with it. And considering the
case of passing an array through to another function, it's currently not
possible to call another pl/perl function from an existing one directly, and
when passing muti-dimensional arrays to a perl function one would need to
convert it to the array references anyway.
>
> - Making the conversion lazy would be a big help.
Converting it to string is already lazy, and, per the argumens above, I don't
see a real benefit of lazy conversion to the perl reference (as comparing to
the hurdles of implementing that).
/A
--
Alexey Klyukin
The PostgreSQL Company - Command Prompt, Inc.
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2011-02-03 12:56:48 | pgsql: Include more status information in walsender results |
Previous Message | Thom Brown | 2011-02-03 11:34:45 | Re: Issues with generate_series using integer boundaries |