From: | "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com> |
---|---|
To: | <mallah(at)trade-india(dot)com> |
Cc: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Dependency tracking while dropping a database. |
Date: | 2003-06-10 18:53:17 |
Message-ID: | Pine.LNX.4.33.0306101247040.13785-100000@css120.ihs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, 10 Jun 2003 mallah(at)trade-india(dot)com wrote:
>
> Hi,
>
> Shudnt' dependency tracking prevent one from dropping
> a database that has tables in it?
Not really.
Dependency tracking is more for things like dropping indexes when the
table that they depend on disappears, or dropping a sequence that was
created with the serial keyword when the table is dropped.
Preventing a database from being dropped is more the job of access
control. I don't think there's any control over who can or can't drop a
database except for the default database creator or superuser.
Of course, since the superuser can type 'rm -Rf $PGDATA/*' you can't
really deny him, just make him work harder to do it. I write a lot of
scripts though, and don't want any default interfacing to have to get done
to drop a database, so I'd prefer it be a non-default setting if any ever
added the ability to deny / grant the creator or superuser the ability to
drop a database.
My intuition tells me that good backups and a test environment are the
answer(s) to this problem.
From | Date | Subject | |
---|---|---|---|
Next Message | Dann Corbit | 2003-06-10 18:55:22 | Re: [GENERAL] MySQL gets $19.5 MM |
Previous Message | Robert Treat | 2003-06-10 18:35:19 | Re: [GENERAL] Postgresql & AMD x86-64 |