Re: PG17beta2: SMGR: inconsistent type for nblocks

On Tue, 30 Jul 2024 at 14:32, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>
> On Tue, Jul 30, 2024 at 11:24 PM Matthias van de Meent
> <boekewurm(at)gmail(dot)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