Date: Tue, 4 Jan 2022 21:06:48 -0600
From: Justin Pryzby <pryzby@telsasoft.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: michael@paquier.xyz, peter.eisentraut@enterprisedb.com,
	pgsql-hackers@lists.postgresql.org, bruce@momjian.us,
	tgl@sss.pgh.pa.us
Subject: Re: GUC flags
Message-ID: <20220105030648.GE14051@telsasoft.com>
References: <YbG7sp+2YEYgbY0D@paquier.xyz>
 <20211209155322.GG17618@telsasoft.com>
 <20211229023240.GM24477@telsasoft.com>
 <20220105.114757.369416916044334409.horikyota.ntt@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220105.114757.369416916044334409.horikyota.ntt@gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: 
 <https://www.postgresql.org/message-id/20220105030648.GE14051%40telsasoft.com>
Precedence: bulk

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