Chris Browne <cbbrowne@acm.org> writes:
> jason.leach@gmail.com ("Jason C. Leach") writes:
>> Why not put pg_hba.conf in a pg table? Seems like it would be much
>> easier to work with. After all, if we can keep users in the db
>> tables, why not this?
> ... Because it represents information that needs to be accessed
> *before* a connection to the database is established.
Right; however, we've already solved the problem of maintaining a
flat-file representation of a cluster-wide table: both pg_database and
pg_shadow/pg_authid are handled that way. I see no reason in principle
why pg_hba.conf couldn't be replaced by a flat-file dump of a database
table.
The interesting part of the problem is designing a tabular
representation that works well and doesn't give up any necessary
features. The existing definition of pg_hba.conf is pretty
non-orthogonal --- in particular its dependence on entry ordering is
nasty if that's to be translated into a table. It'd be better to come
up with a model that doesn't depend on entry order, if we can do that
without sacrificing too much flexibility. And there's too much
variability in what the column entries are --- the notion of tossing a
list or a file inclusion reference into a column may work OK as text,
but it would suck to do that in a table. (But file insertion could
possibly be dispensed with, on the grounds that you could do the
equivalent with pure SQL manipulations.) We've also speculated about
adding a CONNECT privilege to databases, which could cover some of the
ground now occupied by pg_hba.conf.
If we go this route, I'd like to see pg_ident.conf also replaced by
a table, or maybe folded into the same table.
One other small point is the bootstrapping problem: if you can't get
into the database to modify the config table, you've got trouble.
Bottom line is that we need a well-thought-out design proposal first.
The coding would probably be pretty straightforward once we had a
design that would work.
regards, tom lane
