Re: heapgettup() with NoMovementScanDirection unused in core?

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: heapgettup() with NoMovementScanDirection unused in core?
Date: 2023-01-31 20:28:22
Message-ID: CAApHDvoEda6y5zuujf5n7H+2vP8RS2Hbq66XAR6eDN5H8MhqmQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 1 Feb 2023 at 03:02, Melanie Plageman <melanieplageman(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2023-01-31 20:36:20 Re: heapgettup() with NoMovementScanDirection unused in core?
Previous Message Tom Lane 2023-01-31 20:22:02 Re: MacOS: xsltproc fails with "warning: failed to load external entity"