Re: vacuum_truncate configuration parameter and isset_offset

В письме от понедельник, 24 марта 2025 г. 19:41:27 MSK пользователь Nathan
Bossart написал:
> But more importantly, it allows
> us to more closely match the behavior of the existing reloptions with GUCs,
> and it prevents type mismatches (e.g., the reloption is an enum but the GUC
> is a Boolean).

Please do not forget, that reloptions is not the only application of options
mechanism. We have attribute options, opclass options and may have more.
You've just changed the whole engine, for what is seems to be an exceptional
case, that can be solved via existing means. Changing of an engine should not
be done carelessly. You've just make changes for any boolean option of any
postgres object that can ever have options for years and years on. This
change should be done after really good consideration. I strongly suggest to
revert it back, solve the problem via existing means if it needs immediate
solving, and then carefully design boolean-nullable option, or whatever you
want to have, keeping in mind that this changes the whole engine for all
options postgres will ever have. A general design of a new option fature
without anything like "Here I feel like to have this, and there I feel like to
have that". A option type that will be useful for everyone. If it is carefully
considered, I will support it.

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