Re: For cursors, there is FETCH and MOVE, why no TELL?

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Marc Balmer <marc(at)msys(dot)ch>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: For cursors, there is FETCH and MOVE, why no TELL?
Date: 2015-02-10 13:46:23
Message-ID: CAFj8pRANvJLoyA2t3XXL4c4Eyd4OjbH8Oh-NnMCbpqUfonrN2g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2015-02-10 14:32 GMT+01:00 Marc Balmer <marc(at)msys(dot)ch>:

>
>
> 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.
>

I have not strong opinion about it

Pavel

> >
> > 2015-02-09 10:59 GMT+01:00 Marc Balmer <marc(at)msys(dot)ch <mailto:
> marc(at)msys(dot)ch>>:
> >
> > >
> > > 2015-02-09 10:37 GMT+01:00 Marc Balmer <marc(at)msys(dot)ch
> > <mailto:marc(at)msys(dot)ch> <mailto:marc(at)msys(dot)ch <mailto:marc(at)msys(dot)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(at)postgresql(dot)org
> > <mailto:pgsql-hackers(at)postgresql(dot)org>)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgsql-hackers
> >
> >
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-02-10 13:52:09 Re: Parallel Seq Scan
Previous Message Andres Freund 2015-02-10 13:43:22 Re: Assertion failure when streaming logical changes