Re: vacuum_truncate configuration parameter and isset_offset

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Nikolay Shaplov <dhyan(at)nataraj(dot)su>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Treat <rob(at)xzilla(dot)net>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Albe <laurenz(dot)albe(at)cybertec(dot)at>, Gurjeet Singh <gurjeet(at)singh(dot)im>, Will Storey <will(at)summercat(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: vacuum_truncate configuration parameter and isset_offset
Date: 2025-03-26 14:17:12
Message-ID: CAKFQuwbdUSFVRDNSd-NWUTU5yhTRaYdHVrxnqdG32Q27wuhptg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wednesday, March 26, 2025, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

>
> But we also decide things by providing reasons that other people can
> engage with intellectually, and I still say you're not really doing
> that. You're just saying you like X better than Y, but without really
> giving any reason that anybody else can understand and agree with.

The argument being made is that the enum patch adheres to established
practices; and when adding new code that new code is encouraged to adhere
to how existing code is written. A vote to keep to such guidelines seems
reasonable and sufficient; and can outweigh quite a bit of deficiency such
existing code may have relative to the new proposal. The burden is on the
new code to justify why it should violate established conventions.

So, the question posed is should the new way of doing this, established by
the committed patch, be allowed to stay and exist side-by-side with the
original convention for handling the determination of whether an option is
set? I’m +.75 for no and +.25 for yes. Convention tips the balance for me.

David J.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Maksim.Melnikov 2025-03-26 14:17:17 sync_standbys_defined read/write race on startup
Previous Message Christoph Berg 2025-03-26 13:59:30 Re: [PATCH] Add a new pattern for zero-based months for Date/Time Formatting