Enable Config Include in default configuration

[kohlerdominik]

Yesterday, I was debugging a query in our application (with docker compose) and tried to enable some logs. A common pattern for this is to load a config file to some directory, that leaves default config intact but adds some parameters (I use Nginx and PHP containers, for example). So, I was very surprised that enabling some parameters is so hard to do with the Postgres image: it's required to maintain your own config fork, and then it's also required to change the default command?!

---

I did quick research, and learned, that Postgres also can include files of a directory as additional config. Therefore I created this PR to enable a similar experience in this container as well.

I implemented it in a similar way to what is already used to configure the listen_addresses. With this change, it might not be needed to do it that way and we could as well just use a default configuration. I’m up for both, just let me know if I should implement it differently.

Basically, all this PR does is add the creation of the directory /etc/postgresql/conf.d and insert the line include_dir = 'etc/postgresql/conf.d' into the default config.

---

With the suggested changes, it would be way easier to maintain and load one or even multiple config files, especially in local docker compose environments:
For example:

services:
  pg_configdir:
    image: postgres
    volumes:
     - db:/var/lib/postgresql/data
     - ${PWD}/config/postgresql/local/:/etc/postgresql/conf.d

  pg_configfiles:
    image: postgres
    volumes:
     - db:/var/lib/postgresql/data
     - ${PWD}/config/postgresql/local/default.conf:/etc/postgresql/conf.d/10-default.conf
     # - ${PWD}/config/postgresql/local/debug.conf:/etc/postgresql/conf.d/99-debug.conf   #optional: enable only for debugging

[tianon]

See #835

[kohlerdominik]

Thanks @tianon

Great to see that I'm not the only one requesting this. Looks like this a missing feature requested by quite a few people.

[tianon]

Sorry, let me be more clear: I think #835 (comment) still accurately represents our shared maintainer position on this 🙈

[kohlerdominik]

Thanks. I didn't see any arguments against it and interpreted the comment just as quick workaround.

Obviously, you as maintainers have the say in this. Do you mind to share what the reasons are to decline this community request?

[tianon]

Do you mind to share what the reasons are to decline this community request?

Every line of code (especially deviation from upstream defaults) has a concrete maintenance cost and introduces a downstream/user-facing cognitive cost in knowing which things are "Docker PostgreSQL specific" and which things are upstream. We already have a lot of the former, and they absolutely take a toll (both on us and on users). 🖤