Re: PG17beta2: SMGR: inconsistent type for nblocks - Mailing list pgsql-hackers

From Matthias van de Meent
Subject Re: PG17beta2: SMGR: inconsistent type for nblocks
Date
Msg-id CAEze2WiH0QngHfZnsUEhMohgquq_ahMfYCryrG3kqc8MbNzQwA@mail.gmail.com
Whole thread Raw
In response to Re: PG17beta2: SMGR: inconsistent type for nblocks  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: PG17beta2: SMGR: inconsistent type for nblocks
List pgsql-hackers
On Tue, 30 Jul 2024 at 14:32, Thomas Munro <thomas.munro@gmail.com> wrote:
>
> On Tue, Jul 30, 2024 at 11:24 PM Matthias van de Meent
> <boekewurm@gmail.com> wrote:
> > While working on rebasing the patches of Neon's fork onto the
> > REL_17_STABLE branch, I noticed that the nblocks arguments of various
> > smgr functions have inconsistent types: smgrzeroextend accepts
> > `nblocks` as signed integer, as does the new signature for
> > smgrprefetch, but the new vectorized operations of *readv and *writev,
> > and the older *writeback all use an unsigned BlockNumber as indicator
> > for number of blocks.
> >
> > Can we update the definition to be consistent across this (new, or
> > also older) API? As far as I can see, in none of these cases are
> > negative numbers allowed or expected, so updating this all to be
> > consistently BlockNumber across the API seems like a straigthforward
> > patch.
> >
> > cc-ed Thomas as committer of the PG17 smgr API changes.
>
> Yeah, right, I noticed that once myself[1].  For the cases from my
> keyboard, I guess I was trying to be consistent with nearby existing
> stuff in each case, which was already inconsistent...  Do you have a
> patch?

Here's one that covers both master and the v17 backbranch.

Kind regards,

Matthias van de Meent

Attachment

pgsql-hackers by date:

Previous
From: "Andrey M. Borodin"
Date:
Subject: Re: Add LSN <-> time conversion functionality
Next
From: Sutou Kouhei
Date:
Subject: Re: Make COPY format extendable: Extract COPY TO format implementations