Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-bugs by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group