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