Re: vacuum_truncate configuration parameter and isset_offset

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Nikolay Shaplov <dhyan(at)nataraj(dot)su>, "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:40:36
Message-ID: Z-QR5IuTA33Wq3Ns@nathan
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 26, 2025 at 03:30:49PM +0100, Álvaro Herrera wrote:
> On 2025-Mar-26, David G. Johnston wrote:
>> 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.

There's no existing code for an enum reloption that has been hacked to look
like a bool reloption. There are a couple of enums that accept many of the
same values as bool relopts but that also accept another value, but AFAIK
we don't try to pretend that they are actually bools.

> Now -- Nikolay also appears to be saying that we either choose the
> concept of a "default" or the concept of the "isset" flag, but not both.
> That says to me that the other option would be to remove all default
> values and rely solely on isset. Is that a workable option? If it's
> not, then it would be clear to me that we'd rather stick with defaults.
> But if it is, and if that would get us to an overall simplification of
> the concepts, then perhaps that is better. (In other words: for the
> other enums that are currently imitating booleans, can we remove that
> and instead use isset? And are there other uses of default values that
> aren't booleans that can be turned into isset or into something
> different?)

Many of the autovacuum reloptions could use isset. Right now, we use an
out-of-range value as the default so that we can determine whether the
reloption is actually set for the relation. We'd likely still need a
default value field for reloptions without corresponding GUCs, but that
doesn't seem too troublesome to me. TBH I was quite surprised that nobody
had encountered this problem with Boolean reloptions yet.

--
nathan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2025-03-26 14:42:23 Re: vacuum_truncate configuration parameter and isset_offset
Previous Message Nikolay Shaplov 2025-03-26 14:39:58 Re: vacuum_truncate configuration parameter and isset_offset