> 2002-11-12 19:44  momjian
> 
> 	* doc/src/sgml/ref/move.sgml, src/backend/commands/portalcmds.c,
> 	src/backend/executor/execMain.c, src/backend/parser/gram.y,
> 	src/backend/parser/keywords.c, src/backend/tcop/utility.c,
> 	src/include/commands/portalcmds.h, src/include/nodes/parsenodes.h:
> 	Make MOVE/FETCH 0 actually move/fetch 0.  Add MOVE LAST to move to
> 	end of cursor.

Refresh my memory: what is the point of inventing an additional LAST
keyword, when the behavior is exactly the same as MOVE ALL ?

			regards, tom lane

Tue, 07 Jan 2003 18:07:18 -0500
Tom Lane <tgl@sss.pgh.pa.us>
MOVE LAST: why?
Tom Lane wrote:
> > 2002-11-12 19:44  momjian
> > 
> > 	* doc/src/sgml/ref/move.sgml, src/backend/commands/portalcmds.c,
> > 	src/backend/executor/execMain.c, src/backend/parser/gram.y,
> > 	src/backend/parser/keywords.c, src/backend/tcop/utility.c,
> > 	src/include/commands/portalcmds.h, src/include/nodes/parsenodes.h:
> > 	Make MOVE/FETCH 0 actually move/fetch 0.  Add MOVE LAST to move to
> > 	end of cursor.
> 
> Refresh my memory: what is the point of inventing an additional LAST
> keyword, when the behavior is exactly the same as MOVE ALL ?

SQL compatibility, per Peter.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 7 Jan 2003 18:29:02 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: MOVE LAST: why?
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> Refresh my memory: what is the point of inventing an additional LAST
>> keyword, when the behavior is exactly the same as MOVE ALL ?

> SQL compatibility, per Peter.

Oh, I see.  But then really it should be documented as a FETCH keyword,
not only a MOVE keyword.  Will fix.

			regards, tom lane

Tue, 07 Jan 2003 19:05:27 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: MOVE LAST: why? 
Tom Lane wrote:
> 
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> Refresh my memory: what is the point of inventing an additional LAST
> >> keyword, when the behavior is exactly the same as MOVE ALL ?
> 
> > SQL compatibility, per Peter.
> 
> Oh, I see.  But then really it should be documented as a FETCH keyword,
> not only a MOVE keyword.  Will fix.

IIRC *FETCH LAST* doesn't mean *FETCH ALL*.

In addition *FETCH 0* seems to be changed to mean
*FETCH RELATIVE 0* currently. Is it reasonable ? 
*FETCH n* never means *FETCH RELATIVE n*.

regards,
Hiroshi Inoue
	http://w2422.nsk.ne.jp/~inoue/

Wed, 08 Jan 2003 12:41:01 +0900
Hiroshi Inoue <Inoue@tpf.co.jp>
Re: MOVE LAST: why?
Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> IIRC *FETCH LAST* doesn't mean *FETCH ALL*.

SQL92 says

             ii) If the <fetch orientation> implicitly or explicitly spec-
                 ifies NEXT, specifies ABSOLUTE or RELATIVE with K greater
                 than N, or specifies LAST, then CR is positioned after the
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                 last row.
                 ^^^^^^^^

So as far as the ending cursor position is concerned, LAST agrees with
ALL.  It looks to me like the SQL definition only contemplates returning
a single row, but it's less than clear *which* row they mean for LAST.

> In addition *FETCH 0* seems to be changed to mean
> *FETCH RELATIVE 0* currently. Is it reasonable ? 

Sure.  FETCH n in Postgres has always corresponded to FETCH RELATIVE n.

			regards, tom lane

Tue, 07 Jan 2003 22:50:32 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: MOVE LAST: why? 
Tom Lane wrote:
> 
> Sure.  FETCH n in Postgres has always corresponded to FETCH RELATIVE n.

IIRC in SQL standard FETCH retrieves rows one by one.

regards,
Hiroshi Inoue
	http://w2422.nsk.ne.jp/~inoue/

Wed, 08 Jan 2003 13:15:34 +0900
Hiroshi Inoue <Inoue@tpf.co.jp>
Re: MOVE LAST: why?
Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> Tom Lane wrote:
>> Sure.  FETCH n in Postgres has always corresponded to FETCH RELATIVE n.

> IIRC in SQL standard FETCH retrieves rows one by one.

Yes, Postgres' idea of FETCH is only weakly related to the spec's idea.
But I believe you get similar results if you consider only the row last
returned by our FETCH.

			regards, tom lane

Tue, 07 Jan 2003 23:33:21 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: MOVE LAST: why? 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> Refresh my memory: what is the point of inventing an additional LAST
> >> keyword, when the behavior is exactly the same as MOVE ALL ?
> 
> > SQL compatibility, per Peter.
> 
> Oh, I see.  But then really it should be documented as a FETCH keyword,
> not only a MOVE keyword.  Will fix.

Yes. SQL standard doesn't have move, but it has FETCH LAST, so we
borrowed it for MOVE.
-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 7 Jan 2003 23:39:27 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: MOVE LAST: why?
Tom Lane wrote:
> 
> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> > Tom Lane wrote:
> >> Sure.  FETCH n in Postgres has always corresponded to FETCH RELATIVE n.
> 
> > IIRC in SQL standard FETCH retrieves rows one by one.
> 
> Yes, Postgres' idea of FETCH is only weakly related to the spec's idea.
> But I believe you get similar results if you consider only the row last
> returned by our FETCH.

FETCH n is a PostgreSQL's extention to retrieve multiple
rows by one FETCH not related to FETCH RELATIVE at all.

FETCH LAST should return the last one row.
FETCH RELATIVE m should return a row after skipping
m rows if we follow the SQL standard and so the current
implementation of FETCH RELATIVE is broken.

regards,
Hiroshi Inoue
	http://w2422.nsk.ne.jp/~inoue/

Wed, 08 Jan 2003 13:58:30 +0900
Hiroshi Inoue <Inoue@tpf.co.jp>
Re: MOVE LAST: why?
Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> FETCH LAST should return the last one row.

That's not clear to me.  Generally, I would think the cursor should
remain positioned on whatever row is returned, but the spec clearly says
that the final cursor position after FETCH LAST is *after* the last row.
Nor do I see where exactly it says that the last row is the one to
return in this case; the spec seems to treat LAST the same as PRIOR, so
that the *first* row encountered in the movement direction might be the
one to return.  Can you disentangle the spec wording for me?

> FETCH RELATIVE m should return a row after skipping
> m rows if we follow the SQL standard and so the current
> implementation of FETCH RELATIVE is broken.

No objection to that here.  Are you volunteering to make it do that?

			regards, tom lane

Wed, 08 Jan 2003 00:06:15 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: MOVE LAST: why? 
Tom Lane wrote:
> 
> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> > FETCH LAST should return the last one row.
> 
> That's not clear to me.  Generally, I would think the cursor should
> remain positioned on whatever row is returned, but the spec clearly says
> that the final cursor position after FETCH LAST is *after* the last row.

In SQL99 the spec you referred to seems the ii) of b) which
begins with the word *Otherwise*. I see the following before it.

    a) If K is greater than 0 (zero) and not greater than N, then CR
       is positioned on the K-th row of Tt and the corresponding row
       of T. That row becomes the current row of CR.

Then I'm also suspicious if MOVE LAST should mean MOVE ALL.

> > FETCH RELATIVE m should return a row after skipping
> > m rows if we follow the SQL standard and so the current
> > implementation of FETCH RELATIVE is broken.
> 
> No objection to that here.  Are you volunteering to make it do that?

I'm suspicios if we should implement scrollable cursors
with the combination of the current MOVE and FETCH implemen-
tation. For example the backwards FETCH operation for group
nodes isn't implemented properly yet(maybe). Should we fix
it or take another way ? 

regards,
Hiroshi Inoue
	http://w2422.nsk.ne.jp/~inoue/

Wed, 08 Jan 2003 18:31:42 +0900
Hiroshi Inoue <Inoue@tpf.co.jp>
Re: MOVE LAST: why?
I just received and applied the following ODBC patch from Wes Griffin. 
It fixes a foreign key query I broke during my cleanups.

Can we make a new release of ODBC?  Thanks.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

diff -urN psqlodbc.orig/info.c psqlodbc/info.c
--- psqlodbc.orig/info.c	2003-01-03 16:17:59.000000000 -0500
+++ psqlodbc/info.c	2003-01-07 19:12:16.000000000 -0500
@@ -3424,7 +3424,7 @@
 		{
 			schema_strcat(schema_needed, "%.*s", szFkTableOwner, cbFkTableOwner, szFkTableName, cbFkTableName, conn); 	
 			sprintf(tables_query,
-				"SELECT	pt.tgargs, "
+				"SELECT	pt1.tgargs, "
 				"		pt1.tgnargs, "
 				"		pt1.tgdeferrable, "
 				"		pt1.tginitdeferred, "
Wed, 8 Jan 2003 09:59:56 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
ODBC fix
Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> I'm suspicios if we should implement scrollable cursors
> with the combination of the current MOVE and FETCH implemen-
> tation. For example the backwards FETCH operation for group
> nodes isn't implemented properly yet(maybe).

Yeah, backwards scan is not implemented for quite a large number of plan
node types :-(.  I am not sure that it is practical to fix them all.
I have been toying with the notion of making cursors on complex plans
safe for FETCH BACKWARD by sticking a MATERIAL node atop the plan, if
the top plan node isn't one that can handle backwards scan.

The trouble with this of course is that one of the main things people
like to use cursors for is huge result sets, and materializing those is
the last thing you want to do :-(

			regards, tom lane

Wed, 08 Jan 2003 17:42:26 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: MOVE LAST: why? 
I said:
> Yeah, backwards scan is not implemented for quite a large number of plan
> node types :-(.  I am not sure that it is practical to fix them all.
> I have been toying with the notion of making cursors on complex plans
> safe for FETCH BACKWARD by sticking a MATERIAL node atop the plan, if
> the top plan node isn't one that can handle backwards scan.

I forgot to mention plan B: make use of ReScan.  This could work like
so:

1. Cursor keeps track of row number (number of rows it's fetched).

2. To scan backwards when top plan type doesn't handle it, rewind all
the way with ReScan, then move forward the appropriate number of rows.

This would avoid any added overhead in the case where a backwards move
is never requested, and it also would support MOVE BACKWARD ALL quite
efficiently (much more so than now).  On the other hand, it'd really
suck if the user asks for backwards scan from a point far into the
output.

Perhaps we could do something with a hybrid technique: don't materialize
the cursor output unless user actually asks for backwards scan.  If he
does, then create a tuplestore and put the data into it (rescanning the
query output to do so), and finally supply the tuples from the tuplestore.

			regards, tom lane

Wed, 08 Jan 2003 18:05:11 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: MOVE LAST: why? 
Tom Lane wrote:
> 
> Perhaps we could do something with a hybrid technique: don't materialize
> the cursor output unless user actually asks for backwards scan. 

Or we can check the existence of SCROLL keyword which is
currently ignored. In the first place SQL standard only
allows NEXT fetch unless SCROLL is specified.

regards,
Hiroshi Inoue
	http://w2422.nsk.ne.jp/~inoue/

Thu, 09 Jan 2003 08:53:50 +0900
Hiroshi Inoue <Inoue@tpf.co.jp>
Re: MOVE LAST: why?
Tom Lane kirjutas N, 09.01.2003 kell 04:05:
> I said:
> > Yeah, backwards scan is not implemented for quite a large number of plan
> > node types :-(.  I am not sure that it is practical to fix them all.
> > I have been toying with the notion of making cursors on complex plans
> > safe for FETCH BACKWARD by sticking a MATERIAL node atop the plan,

How much work would it be do the MATERIAL node so that it is calculated
at the time of initial forward scan (i.e. FETCH/MOVE) ?

>  if the top plan node isn't one that can handle backwards scan.
> 
> I forgot to mention plan B: make use of ReScan.  This could work like
> so:
> 
> 1. Cursor keeps track of row number (number of rows it's fetched).
> 
> 2. To scan backwards when top plan type doesn't handle it, rewind all
> the way with ReScan, then move forward the appropriate number of rows.
> 
> This would avoid any added overhead in the case where a backwards move
> is never requested, and it also would support MOVE BACKWARD ALL quite
> efficiently (much more so than now).  On the other hand, it'd really
> suck if the user asks for backwards scan from a point far into the
> output.
> 
> Perhaps we could do something with a hybrid technique: don't materialize
> the cursor output unless user actually asks for backwards scan.  If he
> does, then create a tuplestore and put the data into it (rescanning the
> query output to do so), and finally supply the tuples from the tuplestore.

How hard would it be to save "snapshots" of scan state at certain
places, say at each 1000 tuples, so that a full re-scan is not
neccessary  ?

> 			regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
-- 
Hannu Krosing <hannu@tm.ee>

09 Jan 2003 05:00:34 +0500
Hannu Krosing <hannu@tm.ee>
Re: MOVE LAST: why?
Bruce Momjian wrote:
> 
> I just received and applied the following ODBC patch from Wes Griffin.
> It fixes a foreign key query I broke during my cleanups.
> 
> Can we make a new release of ODBC?  Thanks.

Sorry I'm not ready.

regards,
Hiroshi Inoue
	http://w2422.nsk.ne.jp/~inoue/

Thu, 09 Jan 2003 09:49:41 +0900
Hiroshi Inoue <Inoue@tpf.co.jp>
Re: ODBC fix
Tom Lane wrote:
> 
> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> > I'm suspicios if we should implement scrollable cursors
> > with the combination of the current MOVE and FETCH implemen-
> > tation. For example the backwards FETCH operation for group
> > nodes isn't implemented properly yet(maybe).
> 
> Yeah, backwards scan is not implemented for quite a large number of plan
> node types :-(.  I am not sure that it is practical to fix them all.
> I have been toying with the notion of making cursors on complex plans
> safe for FETCH BACKWARD by sticking a MATERIAL node atop the plan, if
> the top plan node isn't one that can handle backwards scan.
> 
> The trouble with this of course is that one of the main things people
> like to use cursors for is huge result sets, and materializing those is
> the last thing you want to do :-(

Honestly I'm not so enthusiastic about scrollable cursors.
Even though PostgreSQL provides an efficient scrollable
cursor, I would use it little unless it could survive
across transactions.

Anyway it's too bad that FETCH LAST means FETCH ALL.

regards, 
Hiroshi Inoue
	http://w2422.nsk.ne.jp/~inoue/

Thu, 09 Jan 2003 12:18:48 +0900
Hiroshi Inoue <Inoue@tpf.co.jp>
Re: MOVE LAST: why?
> Honestly I'm not so enthusiastic about scrollable cursors.
> Even though PostgreSQL provides an efficient scrollable
> cursor, I would use it little unless it could survive
> across transactions.
> 
> Anyway it's too bad that FETCH LAST means FETCH ALL.

I would remove LAST, RELATIVE and SCROLL keywords
for cursor related operations if there's no objection.

regards, 
Hiroshi Inoue

Mon, 13 Jan 2003 01:12:19 +0900
"Hiroshi Inoue" <Inoue@tpf.co.jp>
Re: MOVE LAST: why?
Hiroshi Inoue wrote:
> > Honestly I'm not so enthusiastic about scrollable cursors.
> > Even though PostgreSQL provides an efficient scrollable
> > cursor, I would use it little unless it could survive
> > across transactions.
> > 
> > Anyway it's too bad that FETCH LAST means FETCH ALL.
> 
> I would remove LAST, RELATIVE and SCROLL keywords
> for cursor related operations if there's no objection.

Are you suggesting removing FETCH LAST _and_ MOVE LAST?.  I think MOVE
LAST works well.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Sun, 12 Jan 2003 11:28:09 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: MOVE LAST: why?
Bruce Momjian wrote:
> 
> Hiroshi Inoue wrote:
> > > Honestly I'm not so enthusiastic about scrollable cursors.
> > > Even though PostgreSQL provides an efficient scrollable
> > > cursor, I would use it little unless it could survive
> > > across transactions.
> > >
> > > Anyway it's too bad that FETCH LAST means FETCH ALL.
> >
> > I would remove LAST, RELATIVE and SCROLL keywords
> > for cursor related operations if there's no objection.
> 
> Are you suggesting removing FETCH LAST _and_ MOVE LAST?. 

Yes. Should cursors be positioned on the last row
or EOF by MOVE LAST ? Anyway I see no necessity to use
the standard keyword LAST currently.

> I think MOVE LAST works well.

regards,
Hiroshi Inoue
	http://w2422.nsk.ne.jp/~inoue/

Mon, 13 Jan 2003 08:38:02 +0900
Hiroshi Inoue <Inoue@tpf.co.jp>
Re: MOVE LAST: why?
Hiroshi Inoue wrote:
> > Are you suggesting removing FETCH LAST _and_ MOVE LAST?. 
> 
> Yes. Should cursors be positioned on the last row
> or EOF by MOVE LAST ? Anyway I see no necessity to use
> the standard keyword LAST currently.
> 
> > I think MOVE LAST works well.

OK, so we will switch it to MOVE END.  That seems OK.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Sun, 12 Jan 2003 18:57:12 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: MOVE LAST: why?
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Hiroshi Inoue wrote:
> Are you suggesting removing FETCH LAST _and_ MOVE LAST?. 
>> 
>> Yes. Should cursors be positioned on the last row
>> or EOF by MOVE LAST ? Anyway I see no necessity to use
>> the standard keyword LAST currently.
>> 
> I think MOVE LAST works well.

> OK, so we will switch it to MOVE END.  That seems OK.

What is good about that???  We already have a nonstandard keyword
for this functionality: MOVE ALL.  There is no reason to invent another
one.

I tend to agree with Hiroshi that it's a bad idea to add a standard
keyword to represent not-quite-standard behavior.  MOVE ALL is our
historical spelling for this functionality, and adding MOVE LAST is
not really bringing anything to the party.

			regards, tom lane

Sun, 12 Jan 2003 19:44:50 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: MOVE LAST: why? 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Hiroshi Inoue wrote:
> > Are you suggesting removing FETCH LAST _and_ MOVE LAST?. 
> >> 
> >> Yes. Should cursors be positioned on the last row
> >> or EOF by MOVE LAST ? Anyway I see no necessity to use
> >> the standard keyword LAST currently.
> >> 
> > I think MOVE LAST works well.
> 
> > OK, so we will switch it to MOVE END.  That seems OK.
> 
> What is good about that???  We already have a nonstandard keyword
> for this functionality: MOVE ALL.  There is no reason to invent another
> one.
> 
> I tend to agree with Hiroshi that it's a bad idea to add a standard
> keyword to represent not-quite-standard behavior.  MOVE ALL is our
> historical spelling for this functionality, and adding MOVE LAST is
> not really bringing anything to the party.

OK.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Sun, 12 Jan 2003 19:48:02 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: MOVE LAST: why?
The following patch removes FETCH LAST and instead supports FETCH ALL. 
It also clarifies the docs to mention it sits on the last row, not after
the last row.

Applied.

---------------------------------------------------------------------------

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Hiroshi Inoue wrote:
> > Are you suggesting removing FETCH LAST _and_ MOVE LAST?. 
> >> 
> >> Yes. Should cursors be positioned on the last row
> >> or EOF by MOVE LAST ? Anyway I see no necessity to use
> >> the standard keyword LAST currently.
> >> 
> > I think MOVE LAST works well.
> 
> > OK, so we will switch it to MOVE END.  That seems OK.
> 
> What is good about that???  We already have a nonstandard keyword
> for this functionality: MOVE ALL.  There is no reason to invent another
> one.
> 
> I tend to agree with Hiroshi that it's a bad idea to add a standard
> keyword to represent not-quite-standard behavior.  MOVE ALL is our
> historical spelling for this functionality, and adding MOVE LAST is
> not really bringing anything to the party.
> 
> 			regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
> http://www.postgresql.org/users-lounge/docs/faq.html
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Index: doc/src/sgml/ref/fetch.sgml
===================================================================
RCS file: /cvsroot/pgsql-server/doc/src/sgml/ref/fetch.sgml,v
retrieving revision 1.23
diff -c -c -r1.23 fetch.sgml
*** doc/src/sgml/ref/fetch.sgml	8 Jan 2003 00:22:26 -0000	1.23
--- doc/src/sgml/ref/fetch.sgml	3 Feb 2003 14:00:38 -0000
***************
*** 22,28 ****
    </refsynopsisdivinfo>
    <synopsis>
  FETCH [ <replaceable class="PARAMETER">direction</replaceable> ] [ <replaceable class="PARAMETER">count</replaceable> ] { IN | FROM } <replaceable class="PARAMETER">cursor</replaceable>
! FETCH [ FORWARD | BACKWARD | RELATIVE ] [ <replaceable class="PARAMETER">#</replaceable> | ALL | LAST | NEXT | PRIOR ]
      { IN | FROM } <replaceable class="PARAMETER">cursor</replaceable>
    </synopsis>
  
--- 22,28 ----
    </refsynopsisdivinfo>
    <synopsis>
  FETCH [ <replaceable class="PARAMETER">direction</replaceable> ] [ <replaceable class="PARAMETER">count</replaceable> ] { IN | FROM } <replaceable class="PARAMETER">cursor</replaceable>
! FETCH [ FORWARD | BACKWARD | RELATIVE ] [ <replaceable class="PARAMETER">#</replaceable> | ALL | NEXT | PRIOR ]
      { IN | FROM } <replaceable class="PARAMETER">cursor</replaceable>
    </synopsis>
  
***************
*** 107,123 ****
  
  	 <varlistentry>
  	  <term>
- 	   LAST
- 	  </term>
- 	  <listitem>
- 	   <para>
- 	    Same as <literal>ALL</>, but conforms to SQL92 syntax.
- 	   </para>
- 	  </listitem>
- 	 </varlistentry>
- 
- 	 <varlistentry>
- 	  <term>
  	   NEXT
  	  </term>
  	  <listitem>
--- 107,112 ----
***************
*** 212,218 ****
     If the number of rows remaining in the cursor is less
     than <replaceable class="PARAMETER">#</replaceable>,
     then only those available are fetched.
!    Substituting the keyword ALL or LAST in place of a number will
     cause all remaining rows in the cursor to be retrieved.
     Rows may be fetched in both FORWARD and BACKWARD
     directions. The default direction is FORWARD.
--- 201,207 ----
     If the number of rows remaining in the cursor is less
     than <replaceable class="PARAMETER">#</replaceable>,
     then only those available are fetched.
!    Substituting the keyword ALL in place of a number will
     cause all remaining rows in the cursor to be retrieved.
     Rows may be fetched in both FORWARD and BACKWARD
     directions. The default direction is FORWARD.
***************
*** 220,232 ****
  
    <para>
     The cursor position can be before the first row of the query result, or on
!    any particular row of the result, or after the last row of the result.
     When created, a cursor is positioned before the first row.  After fetching
     some rows, the cursor is positioned on the last row retrieved.  A new
     <command>FETCH</command> always steps one row in the specified direction
     (if possible) before beginning to return rows.  If the
     <command>FETCH</command> requests more rows than available, the cursor is
!    left positioned after the last row of the query result (or before the first
     row, in the case of a backward fetch).  This will always be the case after
     <command>FETCH ALL</>.
    </para>
--- 209,221 ----
  
    <para>
     The cursor position can be before the first row of the query result, or on
!    any particular row of the result.
     When created, a cursor is positioned before the first row.  After fetching
     some rows, the cursor is positioned on the last row retrieved.  A new
     <command>FETCH</command> always steps one row in the specified direction
     (if possible) before beginning to return rows.  If the
     <command>FETCH</command> requests more rows than available, the cursor is
!    left positioned on the last row of the query result (or on the first
     row, in the case of a backward fetch).  This will always be the case after
     <command>FETCH ALL</>.
    </para>
***************
*** 236,242 ****
       A zero row count requests fetching the current row without moving the
       cursor --- that is, re-fetching the most recently fetched row.
       This will succeed unless the cursor is positioned before the
!      first row or after the last row; in which case, no row is returned.
      </para>
     </tip>
  
--- 225,231 ----
       A zero row count requests fetching the current row without moving the
       cursor --- that is, re-fetching the most recently fetched row.
       This will succeed unless the cursor is positioned before the
!      first row; in which case, no row is returned.
      </para>
     </tip>
  
Index: doc/src/sgml/ref/move.sgml
===================================================================
RCS file: /cvsroot/pgsql-server/doc/src/sgml/ref/move.sgml,v
retrieving revision 1.16
diff -c -c -r1.16 move.sgml
*** doc/src/sgml/ref/move.sgml	8 Jan 2003 00:22:26 -0000	1.16
--- doc/src/sgml/ref/move.sgml	3 Feb 2003 14:00:38 -0000
***************
*** 34,40 ****
    </title>
    <para>
     <command>MOVE</command> allows the user to move the cursor position a 
!    specified number of rows, or all the way to the end or start of the query.
     <command>MOVE</command> works exactly like the <command>FETCH</command>
     command, except it only repositions the cursor and does not return rows.
    </para>
--- 34,41 ----
    </title>
    <para>
     <command>MOVE</command> allows the user to move the cursor position a 
!    specified number of rows, or to the beginning or end of the cursor.
!    <command>MOVE ALL</command> moves to the last row of the cursor.
     <command>MOVE</command> works exactly like the <command>FETCH</command>
     command, except it only repositions the cursor and does not return rows.
    </para>
Index: src/backend/parser/gram.y
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/parser/gram.y,v
retrieving revision 2.397
diff -c -c -r2.397 gram.y
*** src/backend/parser/gram.y	2 Feb 2003 23:46:38 -0000	2.397
--- src/backend/parser/gram.y	3 Feb 2003 14:01:13 -0000
***************
*** 361,367 ****
  
  	KEY
  
! 	LANCOMPILER LANGUAGE LAST LEADING LEFT LEVEL LIKE LIMIT
  	LISTEN LOAD LOCAL LOCALTIME LOCALTIMESTAMP LOCATION
  	LOCK_P
  
--- 361,367 ----
  
  	KEY
  
! 	LANCOMPILER LANGUAGE LEADING LEFT LEVEL LIKE LIMIT
  	LISTEN LOAD LOCAL LOCALTIME LOCALTIMESTAMP LOCATION
  	LOCK_P
  
***************
*** 2713,2719 ****
  			Iconst									{ $$ = $1; }
  			| '-' Iconst							{ $$ = - $2; }
  			| ALL									{ $$ = INT_MAX; }
- 			| LAST									{ $$ = INT_MAX; }
  			| NEXT									{ $$ = 1; }
  			| PRIOR									{ $$ = -1; }
  		;
--- 2713,2718 ----
***************
*** 7131,7137 ****
  			| KEY
  			| LANCOMPILER
  			| LANGUAGE
- 			| LAST
  			| LEVEL
  			| LISTEN
  			| LOAD
--- 7130,7135 ----
Index: src/backend/parser/keywords.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/parser/keywords.c,v
retrieving revision 1.132
diff -c -c -r1.132 keywords.c
*** src/backend/parser/keywords.c	12 Dec 2002 20:35:13 -0000	1.132
--- src/backend/parser/keywords.c	3 Feb 2003 14:01:14 -0000
***************
*** 172,178 ****
  	{"key", KEY},
  	{"lancompiler", LANCOMPILER},
  	{"language", LANGUAGE},
- 	{"last", LAST},
  	{"leading", LEADING},
  	{"left", LEFT},
  	{"level", LEVEL},
--- 172,177 ----
Mon, 3 Feb 2003 09:02:41 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: MOVE LAST: why?
Bruce Momjian wrote:
> 
> It also clarifies the docs to mention it sits on the last row, not after
> the last row.

Is it true ? 

regards,
Hiroshi Inoue
	http://www.geocities.jp/inocchichichi/psqlodbc/

Tue, 04 Feb 2003 11:13:46 +0900
Hiroshi Inoue <Inoue@tpf.co.jp>
Re: MOVE LAST: why?
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> > 
> > It also clarifies the docs to mention it sits on the last row, not after
> > the last row.
> 
> Is it true ? 

Oops.  I thought we didn't match the spec because we _didn't_ go past
the last row, but now I see it is because we do go past the last row.

Patch applied to revert.  Thanks.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Index: doc/src/sgml/ref/fetch.sgml
===================================================================
RCS file: /cvsroot/pgsql-server/doc/src/sgml/ref/fetch.sgml,v
retrieving revision 1.24
diff -c -c -r1.24 fetch.sgml
*** doc/src/sgml/ref/fetch.sgml	3 Feb 2003 14:04:24 -0000	1.24
--- doc/src/sgml/ref/fetch.sgml	4 Feb 2003 11:21:20 -0000
***************
*** 209,221 ****
  
    <para>
     The cursor position can be before the first row of the query result, or on
!    any particular row of the result.
     When created, a cursor is positioned before the first row.  After fetching
     some rows, the cursor is positioned on the last row retrieved.  A new
     <command>FETCH</command> always steps one row in the specified direction
     (if possible) before beginning to return rows.  If the
     <command>FETCH</command> requests more rows than available, the cursor is
!    left positioned on the last row of the query result (or on the first
     row, in the case of a backward fetch).  This will always be the case after
     <command>FETCH ALL</>.
    </para>
--- 209,221 ----
  
    <para>
     The cursor position can be before the first row of the query result, or on
!    any particular row of the result, or after the last row of the result.
     When created, a cursor is positioned before the first row.  After fetching
     some rows, the cursor is positioned on the last row retrieved.  A new
     <command>FETCH</command> always steps one row in the specified direction
     (if possible) before beginning to return rows.  If the
     <command>FETCH</command> requests more rows than available, the cursor is
!    left positioned after the last row of the query result (or before the first
     row, in the case of a backward fetch).  This will always be the case after
     <command>FETCH ALL</>.
    </para>
***************
*** 225,231 ****
       A zero row count requests fetching the current row without moving the
       cursor --- that is, re-fetching the most recently fetched row.
       This will succeed unless the cursor is positioned before the
!      first row; in which case, no row is returned.
      </para>
     </tip>
  
--- 225,231 ----
       A zero row count requests fetching the current row without moving the
       cursor --- that is, re-fetching the most recently fetched row.
       This will succeed unless the cursor is positioned before the
!      first row or after the last row; in which case, no row is returned.
      </para>
     </tip>
  
Index: doc/src/sgml/ref/move.sgml
===================================================================
RCS file: /cvsroot/pgsql-server/doc/src/sgml/ref/move.sgml,v
retrieving revision 1.17
diff -c -c -r1.17 move.sgml
*** doc/src/sgml/ref/move.sgml	3 Feb 2003 14:04:24 -0000	1.17
--- doc/src/sgml/ref/move.sgml	4 Feb 2003 11:21:20 -0000
***************
*** 35,41 ****
    <para>
     <command>MOVE</command> allows the user to move the cursor position a 
     specified number of rows, or to the beginning or end of the cursor.
!    <command>MOVE ALL</command> moves to the last row of the cursor.
     <command>MOVE</command> works exactly like the <command>FETCH</command>
     command, except it only repositions the cursor and does not return rows.
    </para>
--- 35,41 ----
    <para>
     <command>MOVE</command> allows the user to move the cursor position a 
     specified number of rows, or to the beginning or end of the cursor.
!    <command>MOVE ALL</command> moves to the end of the cursor.
     <command>MOVE</command> works exactly like the <command>FETCH</command>
     command, except it only repositions the cursor and does not return rows.
    </para>
Tue, 4 Feb 2003 06:23:13 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: MOVE LAST: why?