Re: Dependencies on shared objects
От | Tom Lane |
---|---|
Тема | Re: Dependencies on shared objects |
Дата | |
Msg-id | 2988.1120593092@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Dependencies on shared objects (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: Dependencies on shared objects
|
Список | 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 по дате отправления: