Re: return_next for plperl (was Re: call for help) - Mailing list pgsql-patches

From Andrew Dunstan
Subject Re: return_next for plperl (was Re: call for help)
Date
Msg-id 14018.203.26.206.129.1117921321.squirrel@www.dunslane.net
Whole thread Raw
In response to Re: return_next for plperl (was Re: call for help)  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: return_next for plperl (was Re: call for help)
List pgsql-patches

This has broken the regression tests for plperl - see for example

http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=panda&dt=2005-06-04%2021:20:01
That's because, as Abhijit noted in point 4 below, select foo_srf() no
longer works.

At a minimum those calls need to be removed from the regression tests.

See also my later comments in response to Neil's request of a few days ago.
In particular, I would very much like the callback function renamed to a
simple "return_next".

cheers

andrew


Bruce Momjian said:
>
> Mega-patch version applied.  Thanks.
>
> ---------------------------------------------------------------------------
>
>
> Abhijit Menon-Sen wrote:
>> At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote:
>> >
>> > > The second issue is where plperl returns a large result set.
>>
>> I have attached the following seven patches to address this problem:
>>
>> 1. Trivial. Replaces some errant spaces with tabs.
>>
>> 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many
>>    inane, useless, annoying, and often misleading comments. Here's a
>>    sample: "plperl_init_all() - Initialize all".
>>
>>    (I have tried to add some useful comments here and there, and will
>>    continue to do so now and again.)
>>
>> 3. Trivial. Splits up some long lines.
>>
>> 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize
>>    to return the result set, based on the PL/PgSQL model.
>>
>>    There are two major consequences: result sets will spill to disk
>>    when they can no longer fit in work_mem; and "select foo_srf()" no
>>    longer works. (I didn't lose sleep over the latter, since that form
>>    is not valid in PL/PgSQL, and it's not documented in PL/Perl.)
>>
>> 5. Trivial, but important. Fixes use of "undef" instead of undef. This
>>    would cause empty functions to fail in bizarre ways. I suspect that
>>    there's still another (old) bug here. I'll investigate further.
>>
>> 6. Moves the majority of (4) out into a new plperl_return_next()
>>    function, to make it possible to expose the functionality to
>>    Perl; cleans up some of the code besides.
>>
>> 7. Add an spi_return_next function for use in Perl code.
>>
>> If you want to apply the patches and try them out, 8-composite.diff is
>> what you should use. (Note: my patches depend upon Andrew's use-strict
>> and %_SHARED patches being applied.)
>>
>> Here's something to try:
>>
>>     create or replace function foo() returns setof record as $$
>>     $i = 0;
>>     for ("World", "PostgreSQL", "PL/Perl") {
>>         spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_});
>>     }
>>     return;
>>     $$ language plperl;
>>     select * from foo() as (f1 integer, f2 text, f3 text);
>>




pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: AllocSetReset improvement
Next
From: Bruce Momjian
Date:
Subject: Re: return_next for plperl (was Re: call for help)