Re: Planned change of ExecRestrPos API - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Planned change of ExecRestrPos API
Date
Msg-id 690.1116192300@sss.pgh.pa.us
Whole thread Raw
In response to Planned change of ExecRestrPos API  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I wrote:
> Currently, since nothing is explicitly done to the result Slot of a
> plan node when we restore its position, you might think that the Slot
> still points at the tuple that was current just before the Restore.
> You'd be wrong though, at least for seqscan and indexscan plans
> (I haven't looked yet at the other node types that support
> mark/restore).

Actually, on looking closer, only seqscans have this problem --- and
ExecSeqRestrPos is really dead code anyway at the moment.  So rather
than go through a large exercise to change the mark/restore API, I've
just added some comments about what the API actually guarantees, and
tweaked ExecSeqRestrPos to clear the output slot instead of leaving it
in a potentially inconsistent state.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Oleg Bartunov
Date:
Subject: Re: Best way to scan on-disk bitmaps
Next
From: Alvaro Herrera
Date:
Subject: Re: [ADMIN] Permissions not removed when group dropped