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

Re: Refuse SSL patch

From: Jon Jensen <jon(at)endpoint(dot)com>
To: pgsql-patches(at)postgresql(dot)org
Subject: Re: Refuse SSL patch
Date: 2002-12-12 05:40:09
Message-ID: Pine.LNX.4.50.0212120537590.10772-100000@louche.swelter.net (view raw or flat)
Thread:
Lists: pgsql-patches
On Mon, 9 Dec 2002, Tom Lane wrote:

> Jon Jensen <jon(at)endpoint(dot)com> writes:
> > I haven't seen any previous mention of a similar patch, though I found the
> > following idea proposed by Magnus Hagander which I like:
> 
> >> Perhaps we shuold replace PGREQUIRE_SSL with "PGSSLMODE", being:
> >> 0 - Refuse SSL
> >> 1 - Negotiate, Prefer non-SSL
> >> 2 - Negotiate, Prefer SSL (default)
> >> 3 - Require SSL
> 
> Hm, I like that better than two independent boolean vars (it's not
> obvious which should override the other, or why); moreover it adds
> more functionality (your approach does not provide a way to do mode 1).
> For backwards compatibility, if PGSSLMODE is not set then you could look
> for PGREQUIRE_SSL, and assume mode 3 (rather than the default 2) if
> PGREQUIRE_SSL is set.

I'm working on implementing this now.

> It might be better to use keywords or mnemonics of some kind in place of
> these arbitrary numeric codes.  No strong feeling about that.

I wish I could think of some decent keywords, but the concepts don't lend 
themselves well to short descriptions. I'll start with the numbers Magnus 
suggested, and we can switch to names for the modes later if we want.

> > Is this useful to others? If you'd like me to make some changes to make it 
> > acceptable, please let me know.
> 
> Patches to the relevant documentation would be a minimum requirement.

Ok.

Jon

In response to

pgsql-patches by date

Next:From: Bruce MomjianDate: 2002-12-12 15:46:30
Subject: Re: libpq doc improvement
Previous:From: Tom LaneDate: 2002-12-12 04:14:43
Subject: Re: psql's \d commands --- end of the line for 1-character identifiers?

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