On Tue, 30 Jul 2024 at 14:32, Thomas Munro <thomas.mu...@gmail.com> wrote: > > On Tue, Jul 30, 2024 at 11:24 PM Matthias van de Meent > <boekew...@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
0001-Update-SMGR-API-to-use-consistent-types-for-nblocks-.patch
Description: Binary data
