Re: vacuum_truncate configuration parameter and isset_offset

On Mon, Mar 24, 2025 at 08:57:27PM -0700, David G. Johnston wrote:
> On Mon, Mar 24, 2025 at 11:45 AM Nathan Bossart <nathandbossart(at)gmail(dot)com>
> wrote:
>> * 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.
>
> Fixable for sure.

I've attached an attempt at this.

>> 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.
>
> I'm preferable to turning the implementation into an enum. Slight
> preference to documenting it as the boolean it presently is; pending any
> information regarding where in user-space, particularly in psql but also
> any client-side details, this internal detail might show through. It
> avoids having to tell the reader that we choose enum in order to
> accommodate optionality. But it isn't the end of the world if we do say
> that either.

The only other place I found that reveals this internal implementation
detail is parse_one_reloption. In the attached patch, I've modified it to
emit the same error message as for RELOPT_TYPE_BOOL to further uphold the
illusion that it is a Boolean reloption. I'm not sure I've patched up all
such holes, though.

TBH I find the attached to be even more of a hack than isset_offset. We
have to try to match behavior in multiple places, and we need lengthy
commentary about why you'd want to use this enum. Furthermore, it's only
useful for Boolean-style reloptions, unlike isset_offset which can be used
for any type. But perhaps more importantly, I agree with Robert that it's
not clear what problem it's trying to solve. The concrete arguments in
this thread range from avoiding extra bytes in the struct to maintaining
consistency with other options with backing GUCs, which I'd argue are more
style preferences than anything.

In any case, AFAICT the votes are somewhat evenly divided at the moment, so
I do not intend to proceed with this patch for now.

--
nathan