| 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.
| 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 |