Re: Supporting fallback RADIUS server(s) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Supporting fallback RADIUS server(s)
Date
Msg-id 29205.1440030590@sss.pgh.pa.us
Whole thread Raw
In response to Supporting fallback RADIUS server(s)  (Marko Tiikkaja <marko@joh.to>)
Responses Re: Supporting fallback RADIUS server(s)  (Marko Tiikkaja <marko@joh.to>)
List pgsql-hackers
Marko Tiikkaja <marko@joh.to> writes:
> So I'm developing a patch to fix this issue, but I'm not 
> exactly sure what the configuration should look like.  I see multiple 
> options, but the one I like the best is the following:

> Add two new HBA configuration options: radiusfallbackservers and 
> radiusfallbackports; both lists parsed with SplitIdentifierString (à la 
> listen_addresses).

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?

Or maybe better, rename it radius_servers.  But what you have here seems
weird, and it certainly doesn't follow the precedent of what we did when
we replaced listen_address with listen_addresses.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: proposal: function parse_ident
Next
From: Marko Tiikkaja
Date:
Subject: Re: Supporting fallback RADIUS server(s)