Re: PG vs MySQL - Mailing list pgsql-general

From scott.marlowe
Subject Re: PG vs MySQL
Date
Msg-id Pine.LNX.4.33.0403291418380.22124-100000@css120.ihs.com
Whole thread Raw
In response to Re: PG vs MySQL  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PG vs MySQL
List pgsql-general
On Mon, 29 Mar 2004, Tom Lane wrote:

> "scott.marlowe" <scott.marlowe@ihs.com> writes:
> > 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,
>
> I don't think we want user authentication driven off of actual tables.
> That would mean paying *all* the costs of backend launch before we could
> reject an invalid connection request.
>
> It might be possible to do something with a flat file as an intermediary
> between the postmaster and the tables that are the master data.  We
> already do this for pg_shadow passwords, and I've been thinking of
> proposing that we add a flat file for the database name -> OID mapping
> so we could get rid of the horrid hack that is GetRawDatabaseInfo().
> Per-database flat files would be a bit messy though.

Actually, I had thought of pg_hba as being a global table, not a per
database one.  That would mean only one flat file, wouldn't it?

And while we're at it, maybe we should have a setting somewhere should
someone execute the famous "update pg_shadow set usesuper = false" that
someone did a while back to be able to force an account to be a superuser
account.  In postgresql.conf or something like it.  While it's another
problem, it falls under the same "keeping people from locking themselves
out" thread.


pgsql-general by date:

Previous
From: "Karl O. Pinc"
Date:
Subject: Re: Interval constant syntax, was Re: Interval & check clause
Next
From: Mike Nolan
Date:
Subject: Re: PG vs MySQL