Re: vacuum_truncate configuration parameter and isset_offset - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: vacuum_truncate configuration parameter and isset_offset
Date
Msg-id CAKFQuwbdUSFVRDNSd-NWUTU5yhTRaYdHVrxnqdG32Q27wuhptg@mail.gmail.com
Whole thread Raw
In response to Re: vacuum_truncate configuration parameter and isset_offset  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: vacuum_truncate configuration parameter and isset_offset
Re: vacuum_truncate configuration parameter and isset_offset
List pgsql-hackers
On Wednesday, March 26, 2025, Robert Haas <robertmhaas@gmail.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.

pgsql-hackers by date:

Previous
From: Christoph Berg
Date:
Subject: Re: [PATCH] Add a new pattern for zero-based months for Date/Time Formatting
Next
From: "Maksim.Melnikov"
Date:
Subject: sync_standbys_defined read/write race on startup