list append syntax for postgresql.conf

Em qua, 20 de fev de 2019 às 12:15, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> escreveu:

Nowadays there are a number of methods for composing multiple
postgresql.conf files for modularity. But if you have a bunch of things
you want to load via shared_preload_libraries, you have to put them all
in one setting. How about some kind of syntax for appending something
to a list, like

Partial setting could confuse users, no? I see the usefulness of such
feature but I prefer to implement it via ALTER SYSTEM. Instead of += I
prefer to add another option to ALTER SYSTEM that appends new values
such as:

ALTER SYSTEM APPEND shared_preload_libraries TO 'pg_stat_statements,
pg_prewarm';

and it will expand to:

shared_preload_libraries = 'foo, bar, pg_stat_statements, pg_prewarm'

shared_preload_libraries += 'pg_stat_statements'

What happen if you have:

shared_preload_libraries = 'foo'

then

shared_preload_libraries += 'bar'

and then

shared_preload_libraries = 'pg_stat_statements'

You have only 'pg_stat_statements' or 'foo, bar, pg_stat_statements'?

Suppose you mistype 'bar' as 'baz', do you have only 'pg_stat_statements'?

--
Euler Taveira Timbira -
http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento

Re: Peter Eisentraut 2019-02-20 <74af1f60-34af-633e-ee8a-310d40c741a7@2ndquadrant.com>

Nowadays there are a number of methods for composing multiple
postgresql.conf files for modularity. But if you have a bunch of things
you want to load via shared_preload_libraries, you have to put them all
in one setting. How about some kind of syntax for appending something
to a list, like

shared_preload_libraries += 'pg_stat_statements'

I've thought about that syntax myself in the past. It would be very
handy to be able to things like

/etc/postgresql/11/main/conf.d/pg_stat_statements.conf:
shared_preload_libraries += 'pg_stat_statements'
pg_stat_statements.track = all

(The current Debian packages already create and support conf.d/ in the
default configuration.)

+1.

Christoph

On 2/20/19 10:15 AM, Peter Eisentraut wrote:

Nowadays there are a number of methods for composing multiple
postgresql.conf files for modularity. But if you have a bunch of things
you want to load via shared_preload_libraries, you have to put them all
in one setting. How about some kind of syntax for appending something
to a list, like

shared_preload_libraries += 'pg_stat_statements'

Thoughts?

I like the idea, but presume it would apply to any GUC list, not just
shared_preload_libraries?

Joe

--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development

On Wednesday, February 20, 2019, Peter Eisentraut <
peter.eisentraut@2ndquadrant.com> wrote:

Nowadays there are a number of methods for composing multiple
postgresql.conf files for modularity. But if you have a bunch of things
you want to load via shared_preload_libraries, you have to put them all
in one setting. How about some kind of syntax for appending something
to a list, like

shared_preload_libraries += 'pg_stat_statements'

I would rather just have the behavior for that variable “append mode”,
period. Maybe do it generally for all multi-value variables. It would be
like “add only” permissions - if you don’t want something loaded it cannot
be specified ever, overwrite is not allowed. Get rid of any
order-of-operations concerns.

David J.

On 2/20/19 10:54 AM, Joe Conway wrote:

shared_preload_libraries += 'pg_stat_statements'

I like the idea, but presume it would apply to any GUC list, not just
shared_preload_libraries?

It would be nice if there were some way for extensions to declare
GUC lists (the very thing that recently became explicitly unsupported).

The difficulty seems to be that a GUC may be assigned before the
extension has been loaded to determine whether list syntax should apply.

Could a change like this improve that situation too, perhaps by
deciding that += syntax /implies/ that an as-yet-undeclared GUC is
to be of list form (which could then be checked when the extension
declares the GUC)?

-Chap

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

Nowadays there are a number of methods for composing multiple
postgresql.conf files for modularity. But if you have a bunch of things
you want to load via shared_preload_libraries, you have to put them all
in one setting. How about some kind of syntax for appending something
to a list, like
shared_preload_libraries += 'pg_stat_statements'

Seems potentially useful, but you'd need to figure out how to represent
this in the pg_settings and pg_file_settings views, which currently
suppose that any given GUC's value is determined by exactly one place in
the config file(s).

regards, tom lane

On Wed, Feb 20, 2019 at 10:15 AM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:

Nowadays there are a number of methods for composing multiple
postgresql.conf files for modularity. But if you have a bunch of things
you want to load via shared_preload_libraries, you have to put them all
in one setting. How about some kind of syntax for appending something
to a list, like

shared_preload_libraries += 'pg_stat_statements'

Thoughts?

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Robert Haas <robertmhaas@gmail.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

On 2019-02-21 18:18, Robert Haas wrote:

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.

This line of thought is attractive, but the library lists can be
order-sensitive in case of cooperating libraries, so an approach were
the load order is indeterminate might not work. (It might be worth
exploring ways of making it not order-sensitive. Many trade-offs.)

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services