Re: vacuum_truncate configuration parameter and isset_offset

On Mon, Mar 24, 2025 at 2:45 PM 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.

It's not great. We allow t/f in most places and some people may rely
on it. Having one place be randomly different is not ideal.

I still don't understand what problem we're trying to solve here.
Using a Boolean flag variable to indicate whether some other value is
or is not initialized is an extremely standard programming practice.
I've done it hundreds of times, and I'm sure some of those times are
now part of PostgreSQL. If we're going to change this -- especially in
a way that has potentially user-visible consequences -- we should have
some non-hyperbolic explanation of why it's a problem in this
particular case.

I think that the answer here might be that Nikolay doesn't like this
because it interacts badly with his "New [relation] options engine,"
mentioned upthread. While I'm sympathetic from the point of view that
it is no fun at all to have your patch get sideswiped, either that
patch can be easily adapted to handle the possibility of an is-set
flag or it can't. If it can't, then I think that's a flaw in that
patch, not this one. I think it's been demonstrated that there are
some things that somebody might like to do with the current reloptions
engine that are actually fairly hard to make work. We should be
looking for an engine that is more flexible and can easily accommodate
new needs as they arise. An isset flag is such a minor deviation from
existing practice that it shouldn't be a big deal; in fact, I think
it's surprising we haven't needed it sooner, and I think if an engine
is so opinionated about how things have to work that it can't
accommodate that, it's not a good idea for us to adopt it.

And if I'm wrong in thinking that, then I would like a detailed
technical argument explaining exactly why.

--
Robert Haas
EDB: http://www.enterprisedb.com