Re: Cleaning up nbtree after logical decoding on standby work

On Wed, Jun 7, 2023 at 5:12 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> -1. For me separating the P_NEW path makes a lot of sense, but isn't 16
> material. I don't agree that it's a problem to have heaprel as a parameter in
> a bunch of places that don't strictly need it today.

As I've said, this is primarily about keeping all of the branches
consistent. I agree that there is no particular known consequence to
not doing this, and have said as much several times.

> I don't really understand why the patch does s/heaprel/heapRel/.

That has been the style used within nbtree for many years now.

> Most of these
> functions aren't actually using camelcase parameters? This part of the change
> just blows up the size, making it harder to review.

I wonder what made it impossibly hard to review the first time around.
The nbtree aspects of this work were pretty much written on
auto-pilot. I had no intention of making a fuss about it, but then I
never expected this push back.

--
Peter Geoghegan