Skip site navigation (1) Skip section navigation (2)

Re: control pg_hba.conf via SQL

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, BERTHOULE Emmanuel <pgdev(at)manberth(dot)homeip(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: control pg_hba.conf via SQL
Date: 2006-03-30 03:31:21
Message-ID: 442B5109.1050108@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers

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.
>
>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

In response to

pgsql-hackers by date

Next:From: Tino WildenhainDate: 2006-03-30 05:46:27
Subject: Re: control pg_hba.conf via SQL
Previous:From: David FetterDate: 2006-03-30 03:23:28
Subject: Re: psql \c error

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group