Re: Improving display of octal GUCs

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Rui Zhao <zhaorui126(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tatsuya Kawata <kawatatatsuya0913(at)gmail(dot)com>, fabriziomello(at)gmail(dot)com, pgsql-hackers mailing list <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Jobin Augustine <jobinau(at)gmail(dot)com>
Subject: Re: Improving display of octal GUCs
Date: 2026-09-02 13:00:04
Message-ID: AA0D66DB-D767-4162-9C88-A13954F05CF4@yandex-team.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Tom,

> Perhaps there's a case for checking that GUC_SHOW_IN_OCTAL isn't
> applied to a non-integer GUC, but I can't get too excited about that.

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 wondered whether an octal-only flag would paint us into a corner. I could
not find any GUC customarily displayed in hexadecimal. Accepting hexadecimal
input is a different matter, since the input radix is not retained. So I see
no reason for a more general display-base abstraction until another use
appears.

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.

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

Best regards, Andrey Borodin.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2026-09-02 13:29:59 Re: gist_trgm_ops '=' operator: planner picks it over btree, ~300x slower
Previous Message Alexander Korotkov 2026-09-02 13:00:01 Re: gist_trgm_ops '=' operator: planner picks it over btree, ~300x slower