From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bill Gribble <grib(at)linuxdevel(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: FETCH ALL positions cursor strangely? |
Date: | 2003-05-08 18:00:39 |
Message-ID: | 564.1052416839@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Bill Gribble <grib(at)linuxdevel(dot)com> writes:
> "FETCH n FROM cursor" returns n rows and positions the cursor n rows
> ahead of its current position. That makes sense to me. However, if
> there are n rows in the query, "FETCH ALL FROM cursor" will return n
> rows, but seemingly positions the cursor n+1 rows ahead of its current
> position, as demonstrated in the following transcript.
The cursor can be positioned before the first row, on some row, or after
the last row. FETCH always steps one position in the target
direction before beginning to return rows. FETCH ALL is always going
to leave you positioned after the last row (not on the last row, as you
end up if you FETCH exactly as many rows as there are).
I'm not sure how well this is explained in the docs, but the behavior is
sensible given that model, and I believe it is per SQL spec.
If you'd like to suggest better wording for the docs, feel free ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Gerhard Hintermayer | 2003-05-08 18:21:26 | Re: indices - used by which user ? |
Previous Message | Andrew Sullivan | 2003-05-08 17:30:18 | Re: LC_COLLATE and index usage |