Re: vacuum_truncate configuration parameter and isset_offset

В письме от среда, 26 марта 2025 г. 16:52:09 MSK пользователь Robert Haas
написал:
> But we also decide things by providing reasons that other people can
> engage with intellectually, and I still say you're not really doing
> that. You're just saying you like X better than Y, but without really
> giving any reason that anybody else can understand and agree with.

Then please, listen to a reason. If we add isset_offset, it will make code
inconsistent, because it follow same purpose as unreachable default_value in
other non boolean options. Having two conflicting ways to do same thing is a
bad design.
We can get rid of unreachable default_value in every option and use
isset_offset everywhere to detect unset options, but this will give us lot's of
extra flags in StdRdOptions, and more over we still have case when we have
useful default_value. So code will have to either ignore default_value in
option definition when author imply that he will use isset_offset flag later, or
ignore isset_offset flag when processing option with useful default value. These
two cases, I emphasize, are not directly stated in the code, they are implied
somewhere in author's head, and you will never guess which one is in this
case, until you finish reading, or one need to write a lot of comments.

Please try to expand all this isset_offset-based schema for fillfactor (option
with default value), vacuum_max_threshold (option with unreachable default
value) and vacuum_truncate. If you do it carefully you will see, there is no
way to do it without any conflicts.

Better way, if you want to track if vacuum_truncate is, is to encode it in the
default value somehow, as it have been done before. It will not be boolean
anymore, but it can keep boolean-like behaviour for user.

The most simple way to do this, using current code base, is to use enum. If
this will become common case (And I think it will some day), then we should
add separate data type for it. This would be better then enum. But it will
still have to use unreachable default value to detect unset option, not some
kind of flag.

--
Nikolay Shaplov aka Nataraj
Fuzzing Engineer at Postgres Professional
Matrix IM: @dhyan:nataraj.su