From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: MOVE strangeness |
Date: | 2002-12-26 19:14:40 |
Message-ID: | 2482.1040930080@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Sorry, I am not understanding. If he does:
> ...
> here, isn't he sitting at the start of the fourth row, no?
No. He is sitting *on* the third row. If he now does FETCH 1, he will
advance to and return the fourth row; on the other hand, if he does
FETCH -1, he will back up to and return the second row.
The cursor must be considered to be positioned on its current row, not
between rows, or the SQL-defined operations UPDATE WHERE CURRENT OF and
DELETE WHERE CURRENT OF don't make any sense. (We don't support those
yet, but we should someday.)
BTW, looking at Date and the SQL spec, I now realize that the recently
made change to convert FETCH 0 into a no-op is wrong; per spec, FETCH
RELATIVE 0 means "re-fetch the current row, if any". By analogy, MOVE 0
should probably return "MOVE 1" if you are on a real row, "MOVE 0" if
you are not, corresponding to the number of rows you'd have gotten from
FETCH 0. Ugly, but ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Olivier PRENANT | 2002-12-26 19:19:26 | Re: Problems with 7.3.1 |
Previous Message | Bruce Momjian | 2002-12-26 19:04:07 | Re: MOVE strangeness |
From | Date | Subject | |
---|---|---|---|
Next Message | Nic Ferrier | 2002-12-26 19:24:07 | jdbc driver patch: refcursor types, cursor based querys. |
Previous Message | Bruce Momjian | 2002-12-26 19:04:07 | Re: MOVE strangeness |