Re: Improving display of octal GUCs

Andrey Borodin <x4mmm(at)yandex-team(dot)ru> writes:
> I think this is worth doing because the flag is available to extensions. I
> would also require a nonnegative integer range, or define signed formatting:
> with the current %o, -1 is typically shown as 037777777777 on machines with
> 32-bit int. All three GUCs marked GUC_SHOW_IN_OCTAL by this patch already
> have a minimum of zero.

I don't really feel a need to place such a restriction on the usage of
the flag. %o means unsigned display everywhere, per POSIX, so there's
not a portability argument for it.

> Maybe the new regression test query against pg_settings could also include
> setting and reset_val, as in the opening example. The former would exercise
> the replacement of the old show hooks, while the latter is the only changed
> auxiliary value that the test does not currently check.

Those omissions are intentional, because otherwise the test would fail
in "installcheck" mode on installations with non-default values for
these GUCs. We could avoid that gotcha if we could locally SET the
value to be displayed, but none of these GUCs permit session-level
settings. I didn't think it was worth going to the trouble of, say,
creating a TAP test just so we could exercise that.

> With those small changes, the patch looks ready for committer.

What do you think of Rui's suggestion for a HINT if we're throwing
out-of-range for an octal GUC? I think it's a little more complicated
than he paints it, because the syntax rules are different in
postgresql.conf than in SQL, but we could make it happen if we thought
it was worth the trouble. In the initial draft, I felt that showing
the interpreted value in octal would be enough of a clue, but perhaps
that judgment is wrong.

regards, tom lane