On Sun, Apr 16, 2006 at 03:37:42PM +0200, Tino Wildenhain wrote: > > Apart from the complaint that this makes no attempt to take care of the > > fact that entires in pg_hba.conf are order sensetive. Where is that > > found in this syntax? What about pg_ident.conf? > > there is actually no proof of the current order depency is really > a good idea. Other access lists work without that constraint.
For something that may not be a good idea, it's awfully popular. Firewall chains, tcpwrappers (hosts.allow), SSH config to name but a few. I think you need to demonstrate that an order independant solution is at least as flexble. Even network routing tables, being a common case where order doesn't matter, get layered into tables with an order to deal with complex routing setups. I don't think you can get away from having an order because you have several attributes all equally important (connection type (local/remote), source (ip), ssl(yes/no), database name, user name). How do you decide which to use if multiple match? > > you layer your above grant syntax into those chains. This allow people > > to switch between different auth methods quickly by switching files, > > while allowing people who want to do everything in the database can do > > so too. > > Even with in database rules only you can do the switches - you remove > all entries, keeping your current connection and then bring them > back when you are ready. Just a matter of some SQL commands in a script. But I think you need to keep the concept of "commenting out". Disabling a rule without removing it. And you havn't dealt with the central administration aspect (farm out config files). Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
signature.asc
Description: Digital signature
