On October 17, 2015 4:18:50 PM GMT+02:00, Simon Riggs <si...@2ndquadrant.com> wrote: >On 17 October 2015 at 14:39, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> Andres Freund <and...@anarazel.de> writes: >> > 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. >> >> Indeed. It is completely stupid to do this in any other way except >> by reinstating ssl_renegotiation_limit as an ordinary GUC variable >> whose min and max are both zero. >> > >Agreed, my suggestion requires we can set that GUC, but we can set >not-in-file also. > > >> Quite aside from the implementation effort of inventing some >> single-purpose kluge to do it another way, that solution would also >> cover the complaints we're doubtless gonna get that "SET >> ssl_renegotiation_limit = 0" doesn't work anymore. >> > >Agreed, single purpose kluge is a bad thing. > >Rough patch for the extensible, backpatchable, non-invasive proposal >attached.
This just doesn't make any sense. This way npgsql setting that flag can't be released before a new set of backbranch releases are in widespread use. Otherwise it'll just error out in all those, not just in 9.5 as it's now the case. It breaks compatibility with all unsupported versions of postgres because those will never learn to ignore this driver argument. Without any need. Ffs all were talking about is continuing to accept a guc in 9.5+, which had been accepted for 10+years. --- Please excuse brevity and formatting - I am writing this on my mobile phone. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
