Re: control pg_hba.conf via SQL

On Wednesday 29 March 2006 17:04, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> > 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.
>
> I'm a bit suspicious of proposals that we move either hba or conf into
> SQL tables --- one of the main reasons why they are flat files is so
> you can still edit them after you've hosed them to the point that the
> database won't start or won't let you in. If you don't have a non-kluge
> solution to the DBA-mistake-recovery scenario, this is not going to be
> an improvement.
>

I've often thought that a GUC in postgresql.conf could control whether to use the hba file or an hba table. Most likely you would need to restart the db to toggle control, but if your at the point where you've locked yourself out thisdoesn't seem onerous. If pushing postgresql.conf into 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 restriction is insurmountable.

> Pushing postgresql.conf into a SQL table will also destroy all the work
> that was done recently to allow config sharing across multiple
> installations (eg the recent commit to support "include" goes out the
> window again). If we no longer care about that, why not?
>

Honestly I never cared much about that, and I run several machines that contain 3+ versions of the db on them. Certainly not as much as I would like to enhance remote administration between machines.

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL