On Fri, Nov 29, 2013 at 05:51:28PM +0200, Heikki Linnakangas wrote:
> On 11/29/2013 05:43 PM, Marko Kreen wrote:
> >On Fri, Nov 29, 2013 at 09:25:02AM -0500, Peter Eisentraut wrote:
> >>On Thu, 2013-11-14 at 11:45 +0100, Magnus Hagander wrote:
> >>>I think the default behaviour should be the one we recommend (which
> >>>would be to have the server one be preferred). But I do agree with the
> >>>requirement to have a GUC to be able to remove it
> >>
> >>Is there a reason why you would want to turn it off?
> >
> >GUC is there so old behaviour can be restored.
> >
> >Why would anyone want that, I don't know. In context of PostgreSQL,
> >I see no reason to prefer old behaviour.
>
> Imagine that the server is public, and anyone can connect. The
> server offers SSL protection not to protect the data in the server,
> since that's public anyway, but to protect the communication of the
> client. In that situation, it should be the client's choice what
> encryption to use (if any). This is analogous to using https on a
> public website.
>
> I concur that that's pretty far-fetched. Just changing the behavior,
> with no GUC, is fine by me.
But client can control that behaviour - it just needs to specify
suites it wants and drop the rest.
So only question is that does any client have better (non-tuned?)
defaults than we can set from server.
Considering the whole HTTPS world has answered 'no' to that question
and nowadays server-controlled behaviour is preferred, I think it's
safe to change the behaviour in Postgres too.
--
marko
