From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Cc: | michael(at)paquier(dot)xyz, 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 03:06:48 |
Message-ID: | 20220105030648.GE14051@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jan 05, 2022 at 11:47:57AM +0900, Kyotaro Horiguchi wrote:
> At Tue, 28 Dec 2021 20:32:40 -0600, Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote in
> > On Thu, Dec 09, 2021 at 09:53:23AM -0600, Justin Pryzby wrote:
> > > On Thu, Dec 09, 2021 at 05:17:54PM +0900, Michael Paquier wrote:
> > > One option is to expose the GUC flags in pg_settings, so this can all be done
> > > in SQL regression tests.
> > >
> > > Maybe the flags should be text strings, so it's a nicer user-facing interface.
> > > But then the field would be pretty wide, even though we're only adding it for
> > > regression tests. The only other alternative I can think of is to make a
> > > sql-callable function like pg_get_guc_flags(text guc).
> >
> > Rebased on cab5b9ab2c066ba904f13de2681872dcda31e207.
> >
> > And added 0003, which changes to instead exposes the flags as a function, to
> > avoid changing pg_settings and exposing internally-defined integer flags in
> > that somewhat prominent view.
>
> Just an idea but couldn't we use flags in a series of one-letter flag
> representations? It is more user-friendly than integers but shorter
> than full-text representation.
>
> +SELECT name, flags FROM pg_settings;
> name | flags
> ------------------------+--------
> application_name | ARsec
> transaction_deferrable | Arsec
> transaction_isolation | Arsec
> transaction_read_only | Arsec
It's a good idea.
I suppose you intend that "A" means it's enabled and "a" means it's disabled ?
A => show all
R => reset all
S => not in sample
E => explain
C => computed
Which is enough to support the tests that I came up with:
+ (flags&4) != 0 AS no_show_all,
+ (flags&8) != 0 AS no_reset_all,
+ (flags&32) != 0 AS not_in_sample,
+ (flags&1048576) != 0 AS guc_explain,
+ (flags&2097152) != 0 AS guc_computed
However, I think if we add a field to pg_stat_activity, it would be in a
separate patch, expected to be independently useful.
1) expose GUC flags to pg_stat_activity;
2) rewrite check_guc as a sql regression test;
In that case, *all* the flags should be exposed. There's currently 20, which
means it may not work well after all - it's already too long, and could get
longer, and/or overflow the alphabet...
I think pg_get_guc_flags() may be best, but I'm interested to hear other
opinions.
--
Justin
From | Date | Subject | |
---|---|---|---|
Next Message | Corey Huinker | 2022-01-05 03:17:07 | Re: Suggestion: optionally return default value instead of error on failed cast |
Previous Message | James Coleman | 2022-01-05 02:59:21 | Re: Consider parallel for lateral subqueries with limit |