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: AANLkTi=4Kycovv0JUbFntvoOVRNHCqZaZaJqMZ9UVdMa@mail.gmail.com (view raw or flat)
Thread:
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
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 )

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
Subject: Re: ALTER EXTENSION UPGRADE, v3

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