On Fri, Aug 27, 2021 at 1:19 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Thu, Aug 19, 2021 at 03:58:57PM -0700, David G. Johnston wrote:
> > I'm at -0.5 as to whether such a patch would actually be an improvement or
> > whether the added possibilities would just be confusing and, because it is
> > all optional, indefinitely so.
>
> FWIW, I find this proposition of introducing a set of optional
> synonyms to map with some special-case values we have in the
> configurations a bit confusing, as that's basically introducing
> enum-like options into GUCs that already have a type assigned.
It does use enum-like mappings, but that is just because I needed to
tie together name + value and just reused the already similar data
structure. That could be changed if the code itself is less
understandable based on the struct names.
> The patch, with its set of options like special_disabled0,
> special_disabled_all is not really easy to parse either so that's just
> a recipe to make the set of synonyms to grow on an GUC-basis.
Yes, when I started out on this, I expected maybe 2-3 different
interpretations at most, with more common overlap. I am not tied to
making *every* GUC support this; maybe we support the special_disabled
or special_disabled0 with differing names.
> What I am wondering, though, is if there are cases in the existing
> GUCs, with their existing types, where the situation of a default or
> disabled value could be improved, though, to make the overall picture
> more consistent.
I think this would be possible, although the benefit of what I've
written is that it doesn't change the interpretation of the value
anywhere else, just in GUC parsing (and optionally GUC display). The
parsing was where I felt this improved understanding, I'm less tied to
outputting in the "canonical" way.
