Re: GUC flags
От | Kyotaro Horiguchi |
---|---|
Тема | Re: GUC flags |
Дата | |
Msg-id | 20220105.114757.369416916044334409.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | GUC flags (Justin Pryzby <pryzby@telsasoft.com>) |
Список | pgsql-hackers |
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 regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: