Re: modifying the tbale function - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: modifying the tbale function
Date
Msg-id 45FE9D57.7080207@dunslane.net
Whole thread Raw
In response to Re: modifying the tbale function  (Heikki Linnakangas <heikki@enterprisedb.com>)
Responses Re: modifying the tbale function  (Richard Huxton <dev@archonet.com>)
List pgsql-hackers
Heikki Linnakangas wrote:
> Tom Lane wrote:
>> Neil Conway <neilc@samurai.com> writes:
>>> Returning control to the backend for every row returned would likely 
>>> be excessive, but you could return once every k rows and get most of 
>>> the benefits of both approaches (k might be on the order of 1000).
>>
>> However, this still leaves us with no idea how to persuade perl, tcl,
>> python, et al to cooperate.
>
> It seem like a useful optimization for C-functions, though. I was 
> caught by surprise a while ago when I realized that the way I've been 
> using to create simple test data quickly:
>
>


Actually, I think we could teach the PLs to do it - just not 
transparently, so we'd need to mark which functions used the new 
protocol. Such functions would get a state object as an implied first 
argument, so in plperl it might work like this (for a 
generate_series-like function):
   my $state = shift;   my $low = shift;   my $high = shift;   if ($state->{callstatus} eq 'firstcall')   {
$state->{counter}= $low;   }   elseif ($state->{callstatus} eq 'cleanup')   {      # do cleanup here
$state->{return_status}= 'cleaned';      return;   }   my $next  = $state->{counter}++;   $state->{return_status}  =
$next< $high ? 'result' : 'last_result';   return $next;
 


To support this I think we'd need to do something like:
 create function mygs(int, int)   returns setof int   language plperl   with srfstate   as $$ ... $$;



cheers

andrew





pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: Buildfarm feature request: some way to track/classify failures
Next
From: Teodor Sigaev
Date:
Subject: Re: Indexam interface proposal