<p>On Wednesday 29 March 2006 17:04, Tom Lane wrote:<p>> Andrew Dunstan <andrew@dunslane.net> writes:<p>>
>ISTM that the first requirement is for a sane API that will handle the<p>> > fact that HBA lines are ordered.
Persistencein itself shouldn't be a<p>> > big problem - we already do that with some shared tables,
iirc.<p>><p>>I'm a bit suspicious of proposals that we move either hba or conf into<p>> SQL tables --- one of
themain reasons why they are flat files is so<p>> you can still edit them after you've hosed them to the point that
the<p>>database won't start or won't let you in. If you don't have a non-kluge<p>> solution to the
DBA-mistake-recoveryscenario, this is not going to be<p>> an improvement.<p>><p><p>I've often thought that a GUC
inpostgresql.conf could control whether to use the hba file or an hba table. Most likely you would need to restart the
dbto toggle control, but if your at the point where you've locked yourself out thisdoesn't seem onerous. If pushing
postgresql.confinto the db would negate this plan, we could either allow a command line flag to override the conf/hba
behavior,or force postgresql to use files if started in single operator mode. In any case, I don't think this
restrictionis insurmountable. <p><p>> Pushing postgresql.conf into a SQL table will also destroy all the work<p>>
thatwas done recently to allow config sharing across multiple<p>> installations (eg the recent commit to support
"include"goes out the<p>> window again). If we no longer care about that, why not?<p>><p><p>Honestly I never
caredmuch about that, and I run several machines that contain 3+ versions of the db on them. Certainly not as much as I
wouldlike to enhance remote administration between machines. <p><p>-- <p>Robert Treat<p>Build A Brighter Lamp :: Linux
Apache{middleware} PostgreSQL