Re: Dependencies on shared objects - Mailing list pgsql-patches

From Tom Lane
Subject Re: Dependencies on shared objects
Date
Msg-id 2988.1120593092@sss.pgh.pa.us
Whole thread Raw
In response to Re: Dependencies on shared objects  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: Dependencies on shared objects
List pgsql-patches
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On Tue, Jul 05, 2005 at 02:47:15PM -0400, Tom Lane wrote:
>> Although I don't have any particular objection to the OWNER/NORMAL
>> distinction, your explanation doesn't seem to make sense.  Don't you
>> have to poke the Acl anyway, if it's non-null?  Else the grantor values
>> will be wrong.

> Hum, we don't register a dependency on the owner when registering
> dependencies from the Acl -- we actively skip that (because we know the
> owner has an entry of the other type already).  Is this still an issue?

Not sure.  ISTM the distinction we want to capture is more along the
lines of DEPENDENCY_NORMAL vs DEPENDENCY_AUTO --- that is, we should be
willing to auto-drop grants to a user when dropping the user, but not be
willing to auto-drop objects unless the drop is with CASCADE.  Also,
grants from the user to someone else (using grant options) probably
shouldn't go away without CASCADE either, though this is maybe
debatable.  If you believe the latter then the OWNER/ACL division is
clearly the wrong way to think about it.  So I'd be inclined to use
the NORMAL/AUTO terminology instead.

On the other hand: we might need to be able to express that "this
object's ACL depends on that user" as opposed to "this object depends on
that user" --- if you're really using the dependency type as a flag of
this kind, then we might have to keep it.  I've not gotten that far
in reading the patch yet.

            regards, tom lane

pgsql-patches by date:

Previous
From: "Matthew T. O'Connor"
Date:
Subject: Re: Autovacuum integration patch
Next
From: Tom Lane
Date:
Subject: Re: Dependencies on shared objects