On Mon, Mar 24, 2025 at 8:45 AM Nikolay Shaplov <dh...@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. David J.
