vacuum_truncate configuration parameter and isset_offset
От | Nikolay Shaplov |
---|---|
Тема | vacuum_truncate configuration parameter and isset_offset |
Дата | |
Msg-id | 2176413.otsE0voPBg@thinkpad-pgpro обсуждение исходный текст |
Ответы |
Re: vacuum_truncate configuration parameter and isset_offset
Re: vacuum_truncate configuration parameter and isset_offset |
Список | pgsql-hackers |
Hi! I've tired to rebase my reloptions patch (https:// commitfest.postgresql.org/patch/4688/) and have stuck with 0164a0f9 commit. I am deeply involved with reloptions topic, and I should say that I do not like the idea of isset_offset field All other types, as you have mentioned in commit messages, all other types manages "Not set" feature via some specific default value (like -1 for positive integer for example or "auto" for enums). But you can't do that in boolean, and this is true. If you add isset_offset in this case, it would be useless for all types, except boolean. It will make whole design inconsistent, and this is bad. I would suggest to use enum here to achieve same goal, or add some "trilean" data type that can be "true/false/unset" Current reloption code is already a big mess, there is no reason to make it worse. Can we revert it, and do it again, without adding isset_offset field? I can write some code for it too. Or we can patch it over, but I am afraid something will go wrong and we will stuck with isset_offset forever. I do not want it to happen. PS. I've just looked at code for vacuum_index_cleanup it has very same logic, just replace "auto" with anything you like, and uses enum. Grep for StdRdOptIndexCleanupValues for more info StdRdOptIndexCleanupValues -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su
Вложения
В списке pgsql-hackers по дате отправления: