Magnus Hagander wrote:
> > > > I am thinking we will need load_pg_hba() and write_pg_hba() that
> > > > will load and write the table to pg_hba.conf.
> > >
> > > Yeah, that bit is straghtforward enough, but what about the
> > situation
> > > where dba #1 updates the pg_hba table, at the same time as
> > dba #2 is
> > > editting pg_hba.conf in vi?
> >
> > I don't see any way to fix that. The hope is that the
> > administrator has enough control that this isn't happenening
> > --- it could already happen now if who people edit the same
> > file with different editors/locking systems.
>
> 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.
> 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.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073