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