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

On 02/09/2015 11:37 AM, Marc Balmer wrote:
> 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's the first time I hear anyone wanting that, but I guess it might 
come handy sometimes. I think you'd usually still rather keep track of 
that in the client, though, because it's easy to do, and it avoids the 
extra round-trip to execute the TELL command.

Not sure we'd want to add the TELL keyword for this. Perhaps a 
pg_cursor_pos(<cursor name>) function would be better.

You could fairly easily write an extension to do that, btw. A C function 
could call GetPortalByName() and peek into the PortalData.portalPos field.

- Heikki