On Mon, Mar 24, 2025 at 03:27:35PM +0300, Nikolay Shaplov wrote:
> I would suggest to use enum here to achieve same goal, or add some "trilean"
> data type that can be "true/false/unset"
I did first try making the vacuum_truncate reloption an enum, but I didn't
proceed with that approach for a couple of reasons:
* vacuum_truncate is already a Boolean reloption, so switching it to an
enum would require enumerating all possible values accepted by
parse_bool(), which has the following comment:
/*
* Try to interpret value as boolean value. Valid values are: true,
* false, yes, no, on, off, 1, 0; as well as unique prefixes thereof.
* If the string parses okay, return true, else false.
* If okay and result is not NULL, return the value in *result.
*/
I also considered adding some sort of pluggable parsing functionality or
something like StdRdOptIndexCleanupValues (i.e., a subset of the most
popular values accepted by parse_bool()), but those seemed a little too
complicated for the problem at hand.
* I wasn't sure whether it would be better to expose this third "unset"
value or to make it hidden and for internal use only. The former would
mean we have two ways to declare a reloption "unset." You could either
not set it, or you could explicitly set it to "unset." The latter would
require additional code somewhere, or we could just leave it
undocumented. Both of these approaches seemed like weird user
experiences to me.
Overall, the biggest reason I didn't proceed with the enum is because it
felt like it was making it the user's problem. Rather than just teaching
our code how to determine if a reloption was explicitly set, we'd be
introducing unnecessary complexity to the user, or at least we'd be trying
to closely match the existing functionality in an attempt to hide this
complexity from them.
--
nathan
