Re: SPI cursor functions

From: "Tim Keitt" <tkeitt(at)keittlab(dot)org>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: SPI cursor functions
Date: 2008-10-27 15:17:31
Message-ID: 6262c54c0810270817x58731010sd9ce1a1f4fffcd64@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 24, 2008 at 7:57 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Tim Keitt" <tkeitt(at)keittlab(dot)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/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Martin Pihlak 2008-10-27 15:31:39 Re: SQL/MED compatible connection manager
Previous Message Tom Lane 2008-10-27 15:05:24 Re: ERRORDATA_STACK_SIZE exceeded (server crash)