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
signature.asc
Description: This is a digitally signed message part.
