On Fri, Oct 29, 2010 at 19:56, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.
Here's a patch that does this for HEAD. AFAICT, only ssl_ciphers and
the syslog parameters are actually "user facing parameters" - all the
other ifdef'ed out ones are debug-style parameters.
> In any case, a doc patch would be the right thing for the back branches.
I can look at this too (yes, I know we just wrapped, but I'm working
down the backlog :S). You mean something as simple as "this parameter
is unavailable if the server was not compiled with support for SSL"?
In response to
pgsql-bugs by date
|Next:||From: Ng, Stan||Date: 2010-12-16 00:07:57|
|Subject: Re: index corruption on composite primary key indexes|
|Previous:||From: BERTRAND Joel||Date: 2010-12-15 11:19:35|
|Subject: Re: [8.4.4] Strange bus error on Solaris 10/sparc|