Re: SPI cursor functions - Mailing list pgsql-hackers

From Tim Keitt
Subject Re: SPI cursor functions
Date
Msg-id 6262c54c0810270817x58731010sd9ce1a1f4fffcd64@mail.gmail.com
Whole thread Raw
In response to Re: SPI cursor functions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Oct 24, 2008 at 7:57 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Tim Keitt" <tkeitt@keittlab.org> writes:
>> The docs for FETCH indicate you can fetch from the current row using
>> FORWARD 0, but
>
>>     SPI_scroll_cursor_fetch(someportal, FETCH_FORWARD, 0);
>
>> fails for me. Is there a way to emulate FETCH FORWARD 0 with SPI?
>
> Fails how?  AFAICS that calls the same code that the SQL-level
> FETCH command would.
>
> You do realize that "FORWARD 0" means to re-fetch the current row,
> ie the most recently fetched row?  There isn't any current row in
> the initial state of a cursor.

Yes I do. The problem was my test case wasn't doing what I thought it
was doing. Its working now.

>
>> Also, I noticed that
>>    SPI_scroll_cursor_move(someportal, FETCH_BACKWARD, 1);
>> sets SPI_processed to 0, not 1. Is that the intended behavior?
>
> Well, it is if you don't have any row to move backward to ...

Got it. Again, the test case was screwed up. Also, I was trying
interpret SPI_processed as a kind of error flag, but clearly that's
the wrong way to think about it.

Thanks for the help.

THK

>
>                        regards, tom lane
>



-- 
Timothy H. Keitt
http://www.keittlab.org/


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: ERRORDATA_STACK_SIZE exceeded (server crash)
Next
From: Martin Pihlak
Date:
Subject: Re: SQL/MED compatible connection manager