Re: What happened to SSL_CIPHERS? - Mailing list pgsql-bugs

From Tom Lane
Subject Re: What happened to SSL_CIPHERS?
Date
Msg-id 4591.1288374983@sss.pgh.pa.us
Whole thread Raw
In response to Re: What happened to SSL_CIPHERS?  (Magnus Hagander <magnus@hagander.net>)
Responses Re: What happened to SSL_CIPHERS?  (Robert Haas <robertmhaas@gmail.com>)
Re: What happened to SSL_CIPHERS?  (Magnus Hagander <magnus@hagander.net>)
List pgsql-bugs
Magnus Hagander <magnus@hagander.net> writes:
> On Fri, Oct 29, 2010 at 10:01, Josh Berkus <josh@agliodbs.com> wrote:
>> Mind you, we *also* need a doc patch. ("This parameter is only available if
>> PostgreSQL was built with SSL support").

> Actually, I think it'd be more user friendly to make the parameter
> still exist and be a no-op (maybe show the value NULL?) on non-SSL
> enabled builds. Same goes for all other parameters that depend on a
> specific compile flag. That would make life easier on automated tools
> *and* on people sitting down at a new installation.

Yeah, we're a bit schizophrenic about this.  Some parameters still
exist, but can't be set to any value but "disabled", when the relevant
feature wasn't compiled.  Others just aren't there.

It takes code space and work to make a parameter be present but behave
differently if disabled.  I don't think that we should institute a
blanket policy of requiring that to happen; in particular, there are a
number of debug-type parameters for which I argue that it's not worth
the trouble.  But for user-facing parameters I agree we should do it,
and ssl_ciphers is one of those.

In any case, a doc patch would be the right thing for the back branches.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: What happened to SSL_CIPHERS?
Next
From: Tom Lane
Date:
Subject: Re: [PERFORM] typoed column name, but postgres didn't grump