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
pgsql-bugs by date
|Next:||From: Kevin Grittner||Date: 2010-10-29 18:38:54|
|Subject: Re: typoed column name, but postgres didn't grump|
|Previous:||From: Tom Lane||Date: 2010-10-29 17:48:18|
|Subject: Re: typoed column name, but postgres didn't grump |