Arcadius,
> Privileges could be used to solve this problem. And MySQL has managed to
> get around it ....It seems they have a table named host(s) in the system
> catalog where there is a combination of user<->host<->DB.
Actually, I find the MySQL model very ugly and difficult to manage (and I do
manage a public webserver based on MySQL). If we do implement a in-database
ACL, then I would urge that it *not* be based on MySQL. They have a few
features we would do well to emulate, but this isn't one of them.
> > Also, users would risk a permanent fatal lockout if they mis-configure
pg_hba.
>
> In case a DB is used for storing the config, whenever a new user is
> created, he should be allowed to connect to the server from localhost
> .... and if he wants to connect from more hosts, either the superuser
> adds a new host or GRANTs privilege to him to do it.
I don't see how this solves the problem. I've had to re-build MySQL because
of a mistake updating the users table before causing total lockout.
> And as one of the famous Codd's 12(or 13) laws says:
> All information about the RDBMS should be stored in the system catalog
> and accessible by using a well defined/structured language.....
That's Rule #1, and it does not apply to Access Control Lists, which are not
part of the data but are a technical implementation detail.
> PS: There is no problem with pg_hba.conf if there is only few users in
> the system ...
> But when the number of users start growing, then editing/managing
> pg_hba.conf becomes a bit tedious....and there is noway/(no supported
> way) to allow individual users to do it.
That's your first persuasive argument.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
