Re: control pg_hba.conf via SQL

[Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>]

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> We don't have the luxury of being able just to throw out old stuff 
> because we think it might be neater to do it another way.

Well, we could if there were a groundswell of demand showing that the
pg_hba.conf approach were inadequate (don't think so) or hard to
understand (there you could make an argument --- newbies get it wrong
regularly).  But "I want to manage it via SQL" is not such an argument.

> Of course, if we go for a new scheme that is not order dependent, then 
> inventing a reasonable SQL syntax to support it becomes a heck of a lot 
> easier. Something along the lines of GRANT/REVOKE CONNECT ... should do 
> the trick.

I've been thinking about proposing a database CONNECT right anyway, but
it'd be an additional filter atop the pg_hba.conf rules.  You still need
pg_hba because a CONNECT right could only filter user-and-database
combinations; it would offer no traction on limiting which hosts can
connect, nor on deciding what authentication mechanism to use.

Having said that, though, it does seem that limiting user-and-database
combinations is the main problem for many people, and that allowing that
part to be managed from SQL might defuse the need for manipulating
pg_hba.conf from SQL.  If your pg_hba.conf looks like
	host	all	all	0.0.0.0/32	md5
there's not much call to update it dynamically ...

			regards, tom lane