Added custom options in postgresql.conf file

[franzhcs]

Allow custom options to be added to postgresql.conf file

This PR allows deploying custom options that are appended to the postgresql.conf file.

[gclough]

@elbryan, I'm of two minds about this. It's nice to be able to add custom options if the template is out of date (for example the recently added "data_sync_retry" parameter... but anything that's not a valid GUC will cause PostgreSQL to fail upon startup.

Isn't it a better option to update the template with any missing parameters?

Do you have an example of how this works, and what it fixes?

[franzhcs]

@gclough Albeit agreeing with you, I have also to point out that even with the current template failing at choosing the right value for a parameter yields to the same outcome.

One of the parameters I was looking for was pg_stat_statements.track

[gclough]

@elbryan , that makes perfect sense. I completely ignored the fact that some extensions have custom GUC's that are not in the standard template.

I get the feeling that these lists could get very long, so should we promote using the dash formatting instead of square brackets? Something like:

postgresql_custom_options:
  - postgresql_custom_option: option_blah_blah
    postgresql_custom_option_value: value_blah_blah

or maybe just a list of tuples to make it less verbose:

postgresql_custom_options:
  - (option_blah_blah, value_blah_blah)

And in the template code, could we use more verbose variable names? ...and spaces around the variable names, to match (mostly) the rest of the role?

{% for option in postgresql_custom_options %}
{% for postgresql_custom_option,postgresql_custom_option_value in option.items() %}
{{ postgresql_custom_option }} = {{ postgresql_custom_option_value }}
{% endfor %}
{% endfor %}

I'm open to ideas, and my only motivation is to make this workable when there are a LOT of parameters.

Finally, could you add in the v10 template code?

Thanks.