В письме от понедельник, 24 марта 2025 г. 20:37:50 MSK пользователь David G.
Johnston написал:
> My main concern when first seeing this was adding an integer to every
> single option in the entire system for something that is going to be zero
> 99.9% of the time. A bit bloated but not directly impacting behavior.
That is 100% true.
> I wanted to avoid that by just looking in pg_class.reloptions for the
> vacuum_truncate setting when needed.
This goes against all current practice of options usage. Option is mapped to a
C structure, once loaded it is cached, and reused while cache is still alive.
Doing other way will increase the mess.
> I'd rather do that then turn this into an enum that is masquerading as a
boolean.
I think the core of the problem, is that you still thinking about this option
as a boolean. It is no longer a boolean. It is nullable-boolean, or call it
whatever you want, but not a boolean anymore. It has 3 values available. The
most simple way to implement that is to use enum.
If you want to have not-set/null status marked as a separate flag, you can have
it. But then you should redesign all options to follow that logic: do not use
unreachable default value, but use null/unset flag. That is acceptable, if you
really need this, but should be done to all options. But I do not think it
worth efforts.
--
Nikolay Shaplov aka Nataraj
Fuzzing Engineer at Postgres Professional
Matrix IM: @dhyan:nataraj.su
