| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
| Cc: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, bruce(at)momjian(dot)us, tgl(at)sss(dot)pgh(dot)pa(dot)us |
| Subject: | Re: GUC flags |
| Date: | 2022-01-26 06:29:29 |
| Message-ID: | YfDqSVZlzdzZO9x6@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jan 25, 2022 at 09:44:26PM -0600, Justin Pryzby wrote:
> It seems like an arbitrary and short-sighted policy to expose a handful of
> flags in the view for the purpose of retiring ./check_guc, but not expose other
> flags, because we thought we knew that no user could ever want them.
>
> We should either expose all the flags, or should put them into an undocumented
> function. Otherwise, how would we document the flags argument ? "Shows some
> of the flags" ? An undocumented function avoids this issue.
My vote would be to have a documented function, with a minimal set of
the flags exposed and documented, with the option to expand that in
the future. COMPUTED and EXPLAIN are useful, and allow some of the
automated tests to happen. NOT_IN_SAMPLE and GUC_NO_SHOW_ALL are less
useful for the user, and are more developer oriented, but are useful
for the tests. So having these four seem like a good first cut.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2022-01-26 06:34:23 | Re: Is it correct to update db state in control file as "shutting down" during end-of-recovery checkpoint? |
| Previous Message | Bharath Rupireddy | 2022-01-26 05:36:55 | Re: Printing backtrace of postgres processes |