On Fri, Jan 19, 2018 at 01:55:30PM -0500, Robert Haas wrote: > On Wed, Jan 17, 2018 at 10:02 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Also, this isn't really a good argument against using uniform names >> for parameters that every implementation is certain to have, like >> ssl_key_file. > > Even then, it's not that hard to imagine minor variations between what > different implementations will accept. The most obvious difference is > probably that they might expect different file formats, but it's also > possible that a Windows-specific implementation might allow omitting > the file extension while some other implementation does not, for > example. I agree that it would probably be fairly low-risk to use one > parameter for the key file for every implementation, but I suggest > that it would be cleaner and less prone to confusion if we enforce a > full separation of parameters. That also spares us having to make a > judgement call about which parameters have semantics close enough that > we need not separate them.
Having to debate about the most correct default values for one common parameter depending on N SSL implemententations will likely prove at the end that the most correct answer is just to split all parameters from the start. Some implementations are platform-specific, the format file is one thing that matters. There are also other things like ssl_ciphers which could depend on what kind of cipher types an SSL implementation is able to support... Another thing is that we cannot be 100% sure that one parameter can be set to say GUC_SIGHUP for an SSL implementation and needs to have other modes with another implementations. Of course this can be solved if some ifdefs, but splitting brings clarity. At the end, I agree with the position of Robert to split everything and rename the existing ssl_* parameters to openssl_* if v11 gains a new SSL implementation. -- Michael
signature.asc
Description: PGP signature
