vacuum_truncate configuration parameter and isset_offset
Nikolay Shaplov <dhyan@nataraj.su>
From: Nikolay Shaplov <dhyan@nataraj.su>
To: pgsql-hackers@lists.postgresql.org, Robert Treat <rob@xzilla.net>, Fujii Masao <masao.fujii@oss.nttdata.com>, Albe <laurenz.albe@cybertec.at>, Gurjeet Singh <gurjeet@singh.im>, Nathan Bossart <nathandbossart@gmail.com>, Will Storey <will@summercat.com>, Álvaro Herrera <alvherre@alvh.no-ip.org>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2025-03-24T12:27:35Z
Lists: 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