On Wed, 1 Feb 2023 at 03:02, Melanie Plageman <melanieplageman@gmail.com> wrote:
>
> On Tue, Jan 31, 2023 at 11:46:05PM +1300, David Rowley wrote:
> > My thoughts were that we might want to put them
> > table_scan_getnextslot() and table_scan_getnextslot_tidrange(). My
> > rationale for that was that it makes it more clear to table AM devs
> > that they don't need to handle NoMovementScanDirection.
>
> I previously had the asserts here, but I thought perhaps we shouldn't
> restrict table AMs from using NoMovementScanDirection in whatever way
> they'd like. We care about protecting heapgettup() and
> heapgettup_pagemode(). We could put a comment in the table AM API about
> NoMovementScanDirection not necessarily making sense for a next() type
> function and informing table AMs that they need not support it.
hmm, but the recent discovery is that we'll never call ExecutePlan()
with NoMovementScanDirection, so what exactly is going to call
table_scan_getnextslot() and table_scan_getnextslot_tidrange() with
NoMovementScanDirection?
> So, I would favor having both asserts check that the direction is one of
> forward or backward.
That sounds fine to me.
David