Re: MOVE LAST: why? - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: MOVE LAST: why?
Date
Msg-id 200302031402.h13E2gV26646@candle.pha.pa.us
Whole thread Raw
In response to Re: MOVE LAST: why?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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 ----

pgsql-hackers by date:

Previous
From: Rod Taylor
Date:
Subject: Re: Interactive Documentation - how do you want it
Next
From: Tom Lane
Date:
Subject: Re: Interactive Documentation - how do you want it towork?