Re: Cleaning up nbtree after logical decoding on standby work

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Cleaning up nbtree after logical decoding on standby work
Дата
Msg-id CAH2-Wzkugd17Hz9SaPjsoCLzgztX8Uy++OM4tv9d3D4jkmEUEw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Cleaning up nbtree after logical decoding on standby work  (Andres Freund <andres@anarazel.de>)
Ответы Re: Cleaning up nbtree after logical decoding on standby work  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список 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 по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: running logical replication as the subscription owner
Следующее
От: Noah Misch
Дата:
Сообщение: Re: win32ver data in meson-built postgres.exe