Re: GUC flags

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: pryzby(at)telsasoft(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 02:47:57
Message-ID: 20220105.114757.369416916044334409.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2022-01-05 02:51:52 Re: [HACKERS] logical decoding of two-phase transactions
Previous Message Michael Paquier 2022-01-05 02:37:23 Re: Converting WAL to SQL