Re: Allow ssl_renegotiation_limit in PG 9.5 - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Allow ssl_renegotiation_limit in PG 9.5
Date
Msg-id CANP8+j+M67HnfywGGhmr1BR9ZwDr3R1i_Loz2wTpvH3VpxHx-w@mail.gmail.com
Whole thread Raw
In response to Re: Allow ssl_renegotiation_limit in PG 9.5  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 17 October 2015 at 13:27, Andres Freund <andres@anarazel.de> wrote:
On 2015-10-17 12:49:17 +0100, Simon Riggs wrote:
> Agreed, but I don't like the idea of hardcoding something so horribly
> specific into the server.

What's that specific about accepting the value for 'disabled' for a
feature that's not supported anymore?

Because we don't do that in any other non-supported feature.

Do I really need to explain why a specific, hardcoded kluge is a bad idea?
 
> I'd rather the driver added "driver=npgsql" as an additional parameter in
> the StartupMessage. We can then make the server run some driver specific
> logic, rather than hardcoding something that could cause breakage
> elsewhere. This mechanism would then be extensible to all drivers.

How could this cause breakage alsewhere?

Because we are adding code for use by one specific driver, but doing nothing to ensure it runs only for that driver. We'll forget why we did this and it could cause breakage elsewhere.
 
Having to backpatch a new parameter to all supported versions seems far
more invasive than adding a guc that can only be set to one value.

I doubt it, since as I pointed out the protocol already supports it. The suggested method is principled and extensible. 

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Allow ssl_renegotiation_limit in PG 9.5
Next
From: Simon Riggs
Date:
Subject: Re: a raft of parallelism-related bug fixes