Andreas Karlsson <andr...@proxel.se> writes: > On 09/07/2017 11:34 PM, Tomas Vondra wrote: >> Well, people won't be able to set the inactive options, just like you >> can't set ssl=on when you build without OpenSSL support. But perhaps we >> could simply not include the inactive options into the config file, no?
> Yeah, I have been thinking about how bad it would be to dynamically > generate the config file. I think I will try this. I'm not exactly convinced that dynamically inserting some parameters and not others is a great idea. Remember that people tend to copy postgresql.conf files forward from one installation to another. Or they might decide to rebuild the postmaster for an existing installation with a different SSL library. In any scenario like that, you've not done them any real favor if the config file they have contains no trace of the SSL parameters they need. I think we might be best off just playing it straight and providing a config file that contains a section along these lines: # Parameters for OpenSSL. Leave these commented out if not using OpenSSL. # #ssl_ciphers = 'HIGH:MEDIUM:+3DES:!aNULL' # allowed SSL ciphers #ssl_prefer_server_ciphers = on #ssl_ecdh_curve = 'prime256v1' #ssl_dh_params_file = '' #ssl_cert_file = 'server.crt' #ssl_key_file = 'server.key' #ssl_ca_file = '' #ssl_crl_file = '' # # Parameters for GnuTLS. Leave these commented out if not using GnuTLS. # #gnufoo=... #gnubar=... # # Parameters for macOS TLS. ... you get the idea. As previously noted, it'd be a good idea to rename the existing ssl_xxx parameters to openssl_xxx, except maybe ones that we think will be universal. (But even if we do think that, it might be simpler in the long run to just have three or four totally independent sections of the config file, instead of some common and some library- specific parameters.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers