Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> 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?
I think we should treat pg_hba.conf and postgresql.conf as separate
cases. The proposal was only for pg_hba.conf.
There are several possible ways around the "settings hosed" issue,
including Robert's suggestion of a flag to say "don't read the table,
read this file instead".
I agree about the value of "include" for postgresql.conf.
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
