On Aug 20, 2015 4:16 PM, "Tom Lane" <t...@sss.pgh.pa.us> wrote: > > Magnus Hagander <mag...@hagander.net> writes: > > On Thu, Aug 20, 2015 at 2:36 AM, Marko Tiikkaja <ma...@joh.to> wrote: > >> On 2015-08-20 02:29, Tom Lane wrote: > >>> Why add new GUCs for that? Can't we just redefine radiusserver as a list > >>> of servers to try in sequence, and similarly split radiusport into a list? > > > We could change it to radius_servers and radius_ports, and deprecate but > > keep accepting the old parameters for a release or two. To make it easy, we > > make sure that both parameter names accepts the same format parameter, so > > it's easy enough to just replace it once deprecated. > > Considering that we did no such thing for listen_address, which is of > concern to probably two or three orders-of-magnitude more users than > radiusserver, I don't really see why we'd do it for the RADIUS settings. > > Our expectations about forward compatibility for postgresql.conf entries > have always been pretty low; even more so for not-widely-used settings. > > In any case, wouldn't what you describe simply put off the pain for awhile > (replacing it with confusion in the short term)? Eventually we're going > to break it. >
Well, that's true of any depreciation. And if we throw a log message then people will know about it... That said, I'm not against a clean break with compatibility either. As long as it's clean - like renaming the parameters. /Magnus
