Re: pl/perl example in the doc no longer works in 9.1

Alexey Klyukin <alexk@commandprompt.com>

From: Alexey Klyukin <alexk@commandprompt.com>
To: Alex Hunsaker <badalex@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, "David E. Wheeler" <david@kineticode.com>, Amit Khandekar <amit.khandekar@enterprisedb.com>, hackers@postgresql.org, Alvaro Herrera <alvherre@commandprompt.com>
Date: 2011-10-13T13:47:13Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Convert Postgres arrays to Perl arrays on PL/perl input arguments


On Oct 13, 2011, at 7:09 AM, Alex Hunsaker wrote:

> On Wed, Oct 12, 2011 at 15:33, Alex Hunsaker <badalex@gmail.com> wrote:
>> On Wed, Oct 12, 2011 at 15:00, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
>>>  The core of the problem seems to be that if SvROK(sv) then
>>> the code assumes that it must be intended to convert that to an array or
>>> composite, no matter whether the declared result type of the function is
>>> compatible with such a thing.
>> 
>> Hrm, well 9.0 and below did not get this "right" either:
>> create or replace function test_hash() returns text as $$ return
>> {'a'=>1}; $$ language plperl;
>> select test_array();
>>      test_array
>> -----------------------
>>  ARRAY(0x7fd92384dcb8)
>> (1 row)
>> 
>> create or replace function test_hash() returns text as $$ return
>> {'a'=>1}; $$ language plperl;
>> select test_hash();
>>      test_hash
>> ----------------------
>>  HASH(0x7fd92387f848)
>> (1 row)
>> 
> 
>> Given the output above (both pre 9.1 and post) it seems unless the
>> type is a set or composite we should throw an error. Maybe "PL/Perl
>> function returning type %s must not return a reference" ?
>> 
>>>  It would be more appropriate to drive the
>>> cases off the nature of the function result type, perhaps.
>> 
>> Ill see if I can cook up something that's not too invasive.
> 
> PFA my attempt at a fix.
> 
> This gets rid of of most of the if/else chain and the has_retval crap
> in plperl_handl_func(). Instead we let plperl_sv_to_datum() do most of
> the lifting. It also now handles VOIDOID and checks that the request
> result oid can be converted from the perl structure. For example if
> you passed in a hashref with a result oid that was not an rowtype it
> will error out with "PL/Perl cannot convert hash to non rowtype %s".
> Arrays behave similarly.
> 
> One side effect is you can now return a composite literal where you
> could not before. ( We already let you return array literals )
> 
> The comments might still be a bit sparse-- Im hoping the added errors
> make things a bit more self explanatory.
> 
> A large portion of the diff is added regression tests, testing what
> happens when you return various references.
> 
> Comments?

Looks good at  first sight and passes all regression tests for me.


--
Alexey Klyukin        http://www.commandprompt.com
The PostgreSQL Company – Command Prompt, Inc.