Re: What happened to SSL_CIPHERS?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: What happened to SSL_CIPHERS?
Date: 2010-10-29 17:56:23
Message-ID: 4591.1288374983@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> On Fri, Oct 29, 2010 at 10:01, Josh Berkus <josh(at)agliodbs(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Kevin Grittner 2010-10-29 18:38:54 Re: typoed column name, but postgres didn't grump
Previous Message Tom Lane 2010-10-29 17:48:18 Re: typoed column name, but postgres didn't grump