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

Re: control pg_hba.conf via SQL

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
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-29 22:04:19
Message-ID: 1284.1143669859@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: David FetterDate: 2006-03-29 22:25:08
Subject: Re: Win32 sysconfig -> pg_service.conf
Previous:From: Tom LaneDate: 2006-03-29 21:49:45
Subject: Re: Index vacuum improvements

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