Re: Cleaning up nbtree after logical decoding on standby work - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Cleaning up nbtree after logical decoding on standby work
Date
Msg-id CAH2-Wzkugd17Hz9SaPjsoCLzgztX8Uy++OM4tv9d3D4jkmEUEw@mail.gmail.com
Whole thread Raw
In response to Re: Cleaning up nbtree after logical decoding on standby work  (Andres Freund <andres@anarazel.de>)
Responses Re: Cleaning up nbtree after logical decoding on standby work
List pgsql-hackers
On Wed, Jun 7, 2023 at 5:12 PM Andres Freund <andres@anarazel.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



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: running logical replication as the subscription owner
Next
From: Noah Misch
Date:
Subject: Re: win32ver data in meson-built postgres.exe