From: | Bruno Wolff III <bruno(at)wolff(dot)to> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: domain access privilege |
Date: | 2002-07-20 18:34:10 |
Message-ID: | 20020720183410.GA440@wolff.to |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sat, Jul 20, 2002 at 14:06:30 -0400,
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Bruno Wolff III <bruno(at)wolff(dot)to> writes:
>
> > There can be a similar problem if you temporarily grant someone references
> > to a table to do something and they either create other references you
> > don't want or they refuse to drop the reference later to allow you to
> > drop the table.
>
> You can drop the table whether they want you to or not; the foreign key
> constraint goes away by CASCADE.
I tried this as the user owning the referenced table (using 7.2.1) and
I was unable to do the drop. When I did it as a superuser the referencing
constraint was dropped and then the table.
The message was:
NOTICE: DROP TABLE implicitly drops referential integrity trigger from table "test1"
ERROR: test1: Must be table owner.
Normally you aren't going to give someone references access unless you trust
them, so it isn't a big deal if you need to cooperate with them to drop
a table they are referencing.
I guess using a restricted schema is reasonable for domains you don't want
everyone to use. I can't think of a reason you would want people to see it,
but not be able to use it.
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Birch | 2002-07-20 18:46:21 | Re: timestamped archive data index searches |
Previous Message | Tom Lane | 2002-07-20 18:06:30 | Re: domain access privilege |