On Fri, 21 Mar 2025 at 04:30, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Nathan Bossart <nat...@postgresql.org> writes: > > Since there's presently no way to determine whether a Boolean > > storage parameter is explicitly set or has just picked up the > > default value, this commit also introduces an isset_offset member > > to relopt_parse_elt. > > Uh, what? Why is it a good idea to distinguish those states? > Seems like that risks some very surprising behavior, ie if the > default is "true", why shouldn't that act exactly like an > explicit setting of "true"?
I was thinking about this yesterday as the topic of a user-configurable options for truncation threshold came up in [1]. I find it a bit annoying the boolean vacuum_truncate reloption was added (a few years ago) as we could have instead added a more flexible truncate_scale_factor that could be set to -1 to disable truncation. Maybe it's too late now as reloptions are not easy to remove. Adding this GUC now does put us a bit further down the path of the boolean option. >From [2], it seems there are people around unhappy with the current compile-time settings. If we do end up making those user configurable, then we're going to have a redundant "vacuum_truncate" reloption and a redundant GUC. David [1] https://postgr.es/m/CAApHDvrfngqCpQ09LKdr-BnJEVHW0%3DwAhxfRBnw%3DHJ2645cJPg%40mail.gmail.com [2] https://postgr.es/m/CA%2BYyo5Trs9x03-sc4PpmEXPY9K_B_jbEbNd01RbF%2BvOxs3zVUA%40mail.gmail.com
