Re: vacuum_truncate configuration parameter and isset_offset

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Nikolay Shaplov <dhyan(at)nataraj(dot)su>, Robert Haas <robertmhaas(at)gmail(dot)com>, 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-24 16:54:48
Message-ID: CAKFQuwbEh+viEX+UpBDb0TLugzZn9+Gcgzbzeh3y7FjCqYSx7g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 24, 2025 at 9:41 AM Nathan Bossart <nathandbossart(at)gmail(dot)com>
wrote:

> TBH I'm not understanding the pushback for adding a way to determine
> whether the storage parameter is actually set. It's very simple, and it
> seems like it could be useful elsewhere.

IMO this is superior to using sentinel values for the same purpose, but
those already exist and having both is reasonably unappealing.

But more importantly, it allows
> us to more closely match the behavior of the existing reloptions with GUCs,
> and it prevents type mismatches (e.g., the reloption is an enum but the GUC
> is a Boolean).
>
>
Good point; we could solve this in documentation by simply keeping boolean
if no non-boolean enum values are publicly accessible. But this is part of
why having "set/unset" not use sentinel values is better.

David J.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Pyhalov 2025-03-24 16:56:58 Re: Add semi-join pushdown to postgres_fdw
Previous Message Nikolay Shaplov 2025-03-24 16:53:43 Re: vacuum_truncate configuration parameter and isset_offset