From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, peter(dot)eisentraut(at)enterprisedb(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-05 23:55:17 |
Message-ID: | 20220105235517.GR14051@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jan 05, 2022 at 02:17:11PM +0900, Michael Paquier wrote:
> On Tue, Jan 04, 2022 at 09:06:48PM -0600, Justin Pryzby wrote:
> > I think pg_get_guc_flags() may be best, but I'm interested to hear other
> > opinions.
>
> My opinion on this matter is rather close to what you have here with
> handling things through one extra attribute. But I don't see the
> point of using an extra function where users would need to do a manual
> mapping of the flag bits back to a a text representation of them.
If it were implemented as a function, this would be essentially internal and
left undocumented. Only exposed for the purpose of re-implementing check_guc.
> I would suggest to just add one text[] to pg_show_all_settings
Good idea to use the backing function without updating the view.
pg_settings is currently defined with "SELECT *". Is it fine to enumerate a
list of columns instead ?
Attachment | Content-Type | Size |
---|---|---|
v4-0001-check_guc-fix-absurd-number-of-false-positives.patch | text/x-diff | 3.9 KB |
v4-0002-Expose-GUC-flags-in-SQL-function-retire-.-check_g.patch | text/x-diff | 15.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Smith | 2022-01-05 23:56:33 | Remove trailing comma from enums |
Previous Message | Bruce Momjian | 2022-01-05 23:51:37 | Re: Add 64-bit XIDs into PostgreSQL 15 |