Re: tracking owner of extension-managed objects - Mailing list pgsql-hackers

From Robert Haas
Subject Re: tracking owner of extension-managed objects
Date
Msg-id CA+TgmobBFoWaCJhiX_gXaPfXjucChJiVM8J0LRZ34eo=VvP03w@mail.gmail.com
Whole thread Raw
In response to Re: tracking owner of extension-managed objects  (Chapman Flack <chap@anastigmatix.net>)
Responses Re: tracking owner of extension-managed objects  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
On Mon, Dec 21, 2015 at 3:09 PM, Chapman Flack <chap@anastigmatix.net> wrote:
> On 12/21/2015 02:30 PM, Chapman Flack wrote:
>> On 12/21/2015 12:46 PM, Tom Lane wrote:
>
>>> all, since we don't provide a way for extensions to hook into the DROP
>>> mechanisms.  Perhaps that should be fixed.)
>>
>> That is literally *the very next* e-mail I was going to compose.
>>
>> I was looking at pg_(sh)?depend, ...
>> I can probably cobble around this with some
>> combination of triggers on my own table ('cause that works) and
>> event triggers to grovel through the parse trees of commands that
>> could affect the system object,
>
> right, I can't event-trigger on role commands either, can I?

No, and it wouldn't do what you want anyway, because roles are global
objects spanning all databases.  You can't guarantee that your event
trigger is installed in all of them, and even if you could, there's
nothing particularly useful you can do if you are in database A and
get told that a role is going away, and the stuff you care about
fixing up is in database B.

> What's the lightest-weight object I can create that has an owner,
> and whose disappearance I can be notified of?

Schema?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: SET SESSION AUTHORIZATION superuser limitation.
Next
From: "Joshua D. Drake"
Date:
Subject: Re: Parallel pg_dump's error reporting doesn't work worth squat