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
>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.
In response to
pgsql-hackers by date
|Next:||From: Tino Wildenhain||Date: 2006-03-30 05:46:27|
|Subject: Re: control pg_hba.conf via SQL|
|Previous:||From: David Fetter||Date: 2006-03-30 03:23:28|
|Subject: Re: psql \c error|