> > >>The problem is, pg_hba.conf might be editted via the OS unlike the text > > >>version of pg_shadow which is only editted via the server, which would > > >>make appropriate locking nigh-on impossible afaics.
Alright, sorry to just jump in here in the middle, but I don't see why pg_hba.conf couldn't be made to work just like pg_shadow (or rather, pg_authid or whatever it is now :). It's a file on the disk, created initially by initdb, used for initial backend-startup, but 'owned' by the database. It's also a catalog-table, and the file is written out every time the catalog-table is modified. We could implement some functions, or adjust things like ALTER, to make working with the catalog-table a little nicer/easier, etc. For pg_hba.conf, that seems like the most sensible way (to me, anyway) to make it remotely-administratable. Generally I'd think the same of the other config files, though I do appriciate the concern about how to safely restart remotely and associated with that 'testing' the changes somehow before reverting back. Although, it seems like that could be done with files too I'd think. Upon a remote restart if the backend fails to start with file X, it reverts back to the file it was originally started with. Just my 2c. Thanks, Stephen
signature.asc
Description: Digital signature