Re: list append syntax for postgresql.conf

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: list append syntax for postgresql.conf
Date: 2019-02-21 17:30:16
Message-ID: 26203.1550770216@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I like the idea of solving this problem but I'm not sure it's a good
> idea to add this sort of syntax to postgresql.conf. I think it would
> be more useful to provide a way to tell ALTER SYSTEM that you want to
> append rather than replace, as I see Euler also proposes.

> Another off-ball idea is to maybe allow something like
> shared_preload_statements.pg_stat_statments = 1. The server would
> load all libraries X for which shared_preload_statements.X is set to a
> value that is one of the ways we spell a true value for a Boolean GUC.

Either one of these would avoid the problem of having more than one
place-of-definition of a GUC value, so I find them attractive.
The second one seems a tad more modular, perhaps, and it's also
easier to figure out how to undo a change.

A possible objection to the second one is that it binds us forevermore
to allowing setting of GUCs that weren't previously known, which is
something I don't much care for. But it can probably be constrained
enough to remove the formal indeterminacy: we can insist that all
GUCs named "shared_preload_modules.something" will be booleans, and
then we'll throw error if any of them don't correspond to a known
loadable library.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2019-02-21 17:32:51 Re: psql show URL with help
Previous Message Peter Eisentraut 2019-02-21 17:28:09 psql show URL with help