On Sun, 29 Dec 2002 16:39:37 -0800, Kevin Brown <[EMAIL PROTECTED]>
wrote:
>> > Okay. But then doesn't it make sense for FETCH to fetch the contents
>> > of the row (and subsequent requested rows) that the cursor is
>> > currently on *then* move, and not the other way around?
>This model is extre
Tom Lane wrote:
> > Okay. But then doesn't it make sense for FETCH to fetch the contents
> > of the row (and subsequent requested rows) that the cursor is
> > currently on *then* move, and not the other way around?
>
> No, because WHERE CURRENT OF operates on the row last returned by FETCH,
> acc
Kevin Brown <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> 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 sho
Tom Lane wrote:
> 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.)
Okay. But then doesn't it make
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> Okay, given that, is there really any reason why MOVE should return the
> number of rows that would have been fetched? Why not report the number
> of rows moved? Having two different MOVE commands from the same starting
> positions yield indisti
On Thu, Dec 26, 2002 at 02:14:40PM -0500, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Sorry, I am not understanding. If he does:
> > ...
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> 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
Bruce Momjian <[EMAIL PROTECTED]> 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
FET
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Why does the MOVE -3 return 2?
>
> Because he's successfully backed up over 2 real rows. Had he done FETCH
> -3 in the same situation, he'd have gotten back 2 rows; there is no
> third row it could have returned, so it's hard to argu
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Why does the MOVE -3 return 2?
Because he's successfully backed up over 2 real rows. Had he done FETCH
-3 in the same situation, he'd have gotten back 2 rows; there is no
third row it could have returned, so it's hard to argue that the count
should be a
Tom Lane wrote:
> > This does not happen
> > if I replace the FETCHes by MOVEs.
>
> I'm a little confused by that remark; it seems to me that FETCH and MOVE
> have identical behaviors so far as repositioning the cursor is concerned.
> (Internally, MOVE *is* a FETCH, it just suppresses output of th
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> Here's something that's been bothering me for a while... Perhaps this
> is correct behaviour, but I can't quite see how.
It looks fine to me, given the underlying model of how a cursor works,
which probably isn't really written down anywhere :-(
Here's something that's been bothering me for a while... Perhaps this
is correct behaviour, but I can't quite see how. This does not happen
if I replace the FETCHes by MOVEs.
Here's the reference case:
jtv=> begin;
BEGIN
jtv=> declare c cursor for select * from events;
DECLARE CURSOR
jtv=> fetc
13 matches
Mail list logo
