В письме от понедельник, 24 марта 2025 г. 22:11:19 MSK пользователь Robert Haas написал:
> I think that the answer here might be that Nikolay doesn't like this > because it interacts badly with his "New [relation] options engine," There is no problem with adding isset_offset into "New [relation] options engine", not a bit deal. But it will break all internal logic of reloption. Both current version and my patch > And if I'm wrong in thinking that, then I would like a detailed > technical argument explaining exactly why. You can't have both isset_offset flag and default_value. Either one or another. You can't have them both, it will make whole design inconsistent. We already have default_value. Even for boolean. If you want custom behaviour when option is not set, you set unreachable default value. This is the way it is done for _all_ options that has custom behavior for unset option. Even those that a technically boolean. Why vacuum_truncate should do another way? Either do it the way it have been done before, or suggest total redisign for all oprions that has custom unset behaviour via unreachable defaults. This will be consistent. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su
signature.asc
Description: This is a digitally signed message part.
