On Fri, Jan 19, 2018 at 01:55:30PM -0500, Robert Haas wrote:
> On Wed, Jan 17, 2018 at 10:02 PM, Tom Lane <tgl@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