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