Andrew Dunstan <andrew@dunslane.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 likehost all all 0.0.0.0/32 md5
there's not much call to update it dynamically ...
regards, tom lane
