Skip site navigation (1) Skip section navigation (2)

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

From: Alex Hunsaker <badalex(at)gmail(dot)com>
To: Alexey Klyukin <alexk(at)commandprompt(dot)com>
Cc: Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>, 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 20:21:42
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, Feb 3, 2011 at 05:23, Alexey Klyukin <alexk(at)commandprompt(dot)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

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 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 )

In response to

pgsql-hackers by date

Next:From: davidDate: 2011-02-03 20:54:02
Subject: Re: [HACKERS] Slow count(*) again...
Previous:From: Dimitri FontaineDate: 2011-02-03 19:57:32

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group