On Mon, Mar 24, 2025 at 8:45 AM Nikolay Shaplov <dhyan@nataraj.su> wrote:
> but I don't think it's more > confusing here than for other vacuum reloptions. I have seen people > try to unset vacuum reloptions by using SET to configure them to the > default value rather than by using RESET to remove them. But then > later they change the system default and that table is still nailed to > the old default. I always find myself slightly bemused by this, > because it doesn't seem that hard to me to figure out how it actually > works, but it's definitely a real issue. However, I don't see why the > issue is any more acute for this parameter than any other, and it > certainly does not seem like a good idea to make this parameter work > differently from the other ones.
May be I can agree with you. But this does not explain why we should switch boolean from two possible values into three... It can't have three values for any practical reason. This should not be boolean anymore in this case.
The boolean is two-valued. The state of the reloption is also binary - set or unset (i.e., it is listed in pg_class.reloptions, or not). In the unset state the effective value of a reloption comes from the corresponding GUC (or, lacking that, some hard-coded default). If set, the value comes from the associated boolean. RESET places a reloption into the unset state.
