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
