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

Re: PG vs MySQL

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: Mike Nolan <nolan(at)gw(dot)tssi(dot)com>,"Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>,Alex <alex(at)meerkatsoft(dot)com>, Frank Finner <postgresql(at)finner(dot)de>,<pgsql-general(at)postgresql(dot)org>
Subject: Re: PG vs MySQL
Date: 2004-03-29 19:54:11
Message-ID: Pine.LNX.4.33.0403291252090.22030-100000@css120.ihs.com (view raw or flat)
Thread:
Lists: pgsql-general
On Mon, 29 Mar 2004, Joshua D. Drake wrote:

> > I also wonder how well the pg_hba.conf method will scale.  What happens
> > if there are hundreds of client databases or thousands of entries in 
> > pg_hba.conf?
> 
> Although I personally would like to see a pg_hba table instead of the 
> file, I would have to seariously question your implementation if you had
> hundreds of databases on a single machine.
> 
> If you need separate data spaces for each customer but the application
> uses the same schema, use namespaces within a single database.

since the purpose of the pg_hba.conf file is to ensure that you never 
manage to lock yourself out of your database, might it make sense to have 
a pg_hba table in each database that can be / will be / should be(???) 
overidden by the pg_hba.conf file, thus ensuring you never get locked out, 
but allowing the vast majority of connection configuration to be handled 
by tables, with the pg_hba.conf as an emergency procedure used to get the 
warp engines online in case some drunken ensign starts singing "I'll take 
you home Kathleen" and shuts them down. (i.e. "delete from pg_hba" or 
something like it.)???


In response to

Responses

pgsql-general by date

Next:From: Karl O. PincDate: 2004-03-29 19:58:51
Subject: Interval constant syntax, was Re: Interval & check clause
Previous:From: wespvpDate: 2004-03-29 18:54:25
Subject: Re: 7.4.2 on Solaris 9 - Error

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