Horton

Re: GUC flags

Justin Pryzby <pryzby@telsasoft.com>

View thread View on postgr.es
From: Justin Pryzby <pryzby@telsasoft.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, peter.eisentraut@enterprisedb.com, pgsql-hackers@lists.postgresql.org, bruce@momjian.us, tgl@sss.pgh.pa.us
Date: 2022-01-05T23:55:17Z
Lists: pgsql-hackers

Attachments

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 ?

Commits

  1. Add TAP test to automate the equivalent of check_guc, take two

  2. Retire src/backend/utils/misc/check_guc

  3. Add TAP test to automate the equivalent of check_guc

  4. Add PostgreSQL::Test::Cluster::config_data()

  5. Introduce pg_settings_get_flags() to find flags associated to a GUC

  6. Revert changes about warnings/errors for placeholders.

  7. Improve the description of various GUCs