Tino Wildenhain wrote:
Andrew Dunstan wrote:
ISTM that the first requirement is for a sane API that will handle the
fact that HBA lines are ordered. Persistence in itself shouldn't be a
big problem - we already do that with some shared tables, iirc.
so we might have some functions like:
insert_hba_rule(at_position int, connection_type text, username text,
dbname text, cidr_host text, method text)
move_hba_rule(from_position int, to_position int)
delete_hba_rule(at_position int)
Inventing new SQL syntax might make things a bit tougher.
I dont think it has to be ordered preliminary. Since we are
dealing with subnets and stuff - the ordering already lays
in the data - just like routing tables work: most specific
matches first.
I could think of a solution where pg_hba.conf just
overrides the database table (so you have a starting
point with empty table and/or reentry in case of a
mistake)
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. The current
rules for HBA are order dependent. The issue raised as I understood it
was not to invent a new scheme but to be able to manage it from inside a
postgres session.
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.
Maybe we could do something like this: if there is a pg_hba.conf file
present, then use it as now and ignore the access rights table - if
someone does GRANT/REVOKE CONNECT while under pg_hba.conf then process
it but issue a warning. Maybe there could also be an initdb switch that
gave users a choice.
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
