> > The difference is that if the other admin edited it in vi
> *last week*
> > it will still break with your way, unless every admin
> always rembers
> > to do
> > load_pg_hba() before doing *anything at all*.
>
> Yes, good point. In thinking about this, I think we are
> better having the load() function load the file into a
> temporary table, which can then be modified and flushed down
> to the flat file. Another option is that queries to the
> table automatically read the flat file, but that might force
> writes to the file on first update, so that might be bad.
That would be very bad. You can only flush at controlled times.
> > I fail to see how this is better than just editing the
> file. Because
> > it basically *is* a file editing function limited to pg_hba.conf.
> > Perhaps what we need is a file reader/writer that is
> hardcoded to the
> > pg_hba.conf file?
>
> It allows remote administration, and by using columns for the
> pg_hba.conf lines (except for comments), we are making it
> somewhat easier.
I fail to see a real use-case for somebody editing pg_hba.conf *by hand*
using this. I can see it happening through a tool like phppgadmin or
pgadmin, in which case this will actually make it *harder* to implement.
//Magnus
---------------------------(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
