Re: For cursors, there is FETCH and MOVE, why no TELL? - Mailing list pgsql-hackers
From | Pavel Stehule |
---|---|
Subject | Re: For cursors, there is FETCH and MOVE, why no TELL? |
Date | |
Msg-id | CAFj8pRANvJLoyA2t3XXL4c4Eyd4OjbH8Oh-NnMCbpqUfonrN2g@mail.gmail.com Whole thread Raw |
In response to | Re: For cursors, there is FETCH and MOVE, why no TELL? (Marc Balmer <marc@msys.ch>) |
List | pgsql-hackers |
2015-02-10 14:32 GMT+01:00 Marc Balmer <marc@msys.ch>:
Am 10.02.15 um 09:06 schrieb Pavel Stehule:That is simple indeed. I tend to think, however, that it would be> 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);
> }
>
> /*
>
cleaner to return the position as a proper result from a functionn
instead of using a "side effect" from a FETCH/MOVE command.
I have not strong opinion about it
Pavel
>
> 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>>>:> <mailto:pgsql-hackers@postgresql.org>)> >
> > 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
pgsql-hackers by date: