Re: For cursors, there is FETCH and MOVE, why no TELL? - Mailing list pgsql-hackers

From Marc Balmer
Subject Re: For cursors, there is FETCH and MOVE, why no TELL?
Date
Msg-id 54DA085D.1060702@msys.ch
Whole thread Raw
In response to Re: For cursors, there is FETCH and MOVE, why no TELL?  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: For cursors, there is FETCH and MOVE, why no TELL?  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: For cursors, there is FETCH and MOVE, why no TELL?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

Am 10.02.15 um 09:06 schrieb Pavel Stehule:
> Hi
> 
> 
> the patch can be very simple:
> 
> diff --git a/src/backend/commands/portalcmds.c
> b/src/backend/commands/portalcmds.c
> new file mode 100644
> index 2794537..20b9206
> *** a/src/backend/commands/portalcmds.c
> --- b/src/backend/commands/portalcmds.c
> *************** PerformPortalFetch(FetchStmt *stmt,
> *** 181,189 ****
>  
>         /* Return command status if wanted */
>         if (completionTag)
> !               snprintf(completionTag, COMPLETION_TAG_BUFSIZE, "%s %ld",
>                                  stmt->ismove ? "MOVE" : "FETCH",
> !                                nprocessed);
>   }
>  
>   /*
> --- 181,190 ----
>  
>         /* Return command status if wanted */
>         if (completionTag)
> !               snprintf(completionTag, COMPLETION_TAG_BUFSIZE, "%s %ld
> %ld",
>                                  stmt->ismove ? "MOVE" : "FETCH",
> !                                nprocessed,
> !                                portal->portalPos);
>   }
>  
>   /*
> 

That is simple indeed.  I tend to think, however, that it would be
cleaner to return the position as a proper result from a functionn
instead of using a "side effect" from a FETCH/MOVE command.

> 
> 2015-02-09 10:59 GMT+01:00 Marc Balmer <marc@msys.ch <mailto:marc@msys.ch>>:
> 
>     >
>     > 2015-02-09 10:37 GMT+01:00 Marc Balmer <marc@msys.ch
>     <mailto:marc@msys.ch> <mailto:marc@msys.ch <mailto:marc@msys.ch>>>:
>     >
>     >     Currently there are FETCH and the (non standard) MOVE commands to work
>     >     on cursors.
>     >
>     >     (I use cursors to display large datasets in a page-wise way, where the
>     >     user can move per-page, or, when displaying a single record, per record.
>     >      When the user goes back from per-record view to page-view, I have to
>     >     restore the cursor to the position it was on before the user changed to
>     >     per-record view.)
>     >
>     >     I have to "manually" keep track of the cursor position, but in some
>     >     cases it would definitely be easier to just query the current cursor
>     >     position directly from the database and later use "MOVE ABSOLUTE" to
>     >     rewind it to that position.  That could be achieved e.g. by a
>     >     hypothetical "TELL <cursor-name>" command.  It does, however, not exist
>     >     and I have not found an alternative.  Is there a way to query the
>     >     current cusros position at all?  If not, does a TELL command sound like
>     >     a good or bad idea?
>     >
>     >
>     > It sounds like good idea.
>     >
>     > Do we need a new statement? We can implement returning the position to
>     > MOVE statement. It returns a delta, but it can returns a absolute
>     > position too.
> 
>     On second thought, a new statement is not needed at all.  As Heikki
>     noticed in hsi reply, it could either be a new function or have move to
>     return the current position somehow(tm).  Or a nw option to move, maybe
>     "MOVE NOT" (don't move the cursor but return it's position?
> 
> 
>     --
>     Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
>     <mailto:pgsql-hackers@postgresql.org>)
>     To make changes to your subscription:
>     http://www.postgresql.org/mailpref/pgsql-hackers
> 
> 



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Table-level log_autovacuum_min_duration
Next
From: Michael Paquier
Date:
Subject: Re: Patch: add recovery_timeout option to control timeout of restore_command nonzero status code