В письме от понедельник, 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
signature.asc
Description: This is a digitally signed message part.
