On Thu, Feb 3, 2011 at 05:23, Alexey Klyukin <al...@commandprompt.com> wrote:
> Hi,
>
> On Feb 2, 2011, at 7:16 PM, Tim Bunce wrote:
>
[...]
>> 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,
*cough* array string and Oid for the datatype right? :P
> 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.
Sorry, there does seem to be some confusion here. The first version I
posted did lazy conversion to a string using encode_array_literal().
Unfortunately that function falls over with row/composite types. I
don't see a way to quote those without knowing the datatype, so in
interest of having it be 'correct' instead of fast, I made it always
decode to an array ref _and_ string in the next version :-(.
I see a couple of ways to fix this:
1) Using PTR2IV store the datum pointer in the array pseudo object.
This way when used as a string we have the original Datum and can call
the correct OutputFunction on demand. It would also let us call
plperl_ref_from_pg_array lazily. I have not actually tried it, but it
should work.
2) Add encode_composite_literal($hashref, $typeoid) and store the
type/Oid in the pseudo object. We could then call that lazily from the
perl.
3) Add the column position to the pseudo object and quote
appropriately. Simpler than #1 or #2 but not as robust.
4) Maybe there is a way of setting composite columns by column instead
of by position? If so we can encode that way. However everything on
http://www.postgresql.org/docs/current/interactive/rowtypes.html that
has to do with the 'literal' format seems to be positional.
5) Decided its worth the performance hit to always decode to both. (
Note it may not be as big as people think, in the case that you return
the array reference we have to convert it to a string anyway )
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
