Re: control pg_hba.conf via SQL - Mailing list pgsql-hackers

From Tom Lane
Subject Re: control pg_hba.conf via SQL
Date
Msg-id 1284.1143669859@sss.pgh.pa.us
Whole thread Raw
In response to Re: control pg_hba.conf via SQL  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: control pg_hba.conf via SQL  (Robert Treat <xzilla@users.sourceforge.net>)
Re: control pg_hba.conf via SQL  (Andrew Dunstan <andrew@dunslane.net>)
Re: control pg_hba.conf via SQL  (Svenne Krap <svenne@krap.dk>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.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.

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?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Index vacuum improvements
Next
From: David Fetter
Date:
Subject: Re: Win32 sysconfig -> pg_service.conf