Re: vacuum_truncate configuration parameter and isset_offset

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

On Mon, Mar 24, 2025 at 09:03:11PM +0300, Nikolay Shaplov wrote:
> В письме от понедельник, 24 марта 2025 г. 20:48:29 MSK пользователь Nathan
> Bossart написал:
>
>> For the sake of discussion, here is what the enum approach would look like.
>
> In my point of view this solution is much-much better: it achieves all goals,
> has no drawbacks, and do not change reloption engine.

I think this change would probably work fine, but it does have a couple of
drawbacks:

* We'll need to make it really clear in comments why you would want to use
this enum instead of making it a Boolean reloption. That's not a big
deal.

* We'd need to decide what to say on the documentation side. My first
instinct is that we should just leave it as "boolean" because otherwise
we're going to describe something that sounds an awful lot like a
Boolean.

* I don't think this matches the parse_bool() behavior exactly. For
example, parse_bool() appears to accept inputs like "t" to mean "true".
This is also probably not a huge deal.

That being said, I'm open to applying this patch if it seems like a
majority of folks prefer this implementation. FWIW I'm still partial to
the isset_offset approach for the reasons I've already discussed.

--
nathan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Lukas Fittl 2025-03-24 18:47:40 Re: Proposal - Allow extensions to set a Plan Identifier
Previous Message Tom Lane 2025-03-24 18:24:34 Re: Add Postgres module info