Scott Marlowe <[EMAIL PROTECTED]> writes:
> On Tue, 2006-02-07 at 15:37, Michael Fuhr wrote:
>> On Tue, Feb 07, 2006 at 03:24:01PM -0500, Tom Lane wrote:
>>> One other small point is the bootstrapping problem: if you can't get
>>> into the database to modify the config table, you've got trouble.
>>
>> Hence MySQL's --skip-grant-tables option; if you've locked yourself
>> out then you have to disable security entirely to get back in and
>> fix the problem. With a configuration that you can edit from outside
>> the database, you can usually get back in without having to punch
>> as big a hole.
> And you can change pg_hba.conf on the fly, so you don't have to restart
> a 24/7 database because you locked the superuser out.
If your back were against the wall, you could probably hand-edit the
flat-file version of the permission file enough to let yourself in
without shutting down the postmaster. It might not be as user-friendly
to edit as the current pg_hba.conf, but it'd still be flat ASCII I expect.
Also, we already have various scenarios in which dropping down to a
standalone backend is the only recovery path --- deleting the last
superuser role is a good example. So I'm not sure we should insist
that the connection permission file/table has to be any more robust
against superuser stupidity.
The case that I am most worried about is the new-installation scenario:
what will the startup default be, and how hard will be it be to fix it
if you don't like it? This is a big problem for first-timers already,
and we mustn't make it worse. But perhaps there's an opportunity here
to make it better.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
