Re: sql_drop Event Trigger - Mailing list pgsql-hackers

From Robert Haas
Subject Re: sql_drop Event Trigger
Date
Msg-id CA+TgmobdJwhoy=R-pMOSDGyEsJLaoPzmL+JseZQ59R-_HzKLrg@mail.gmail.com
Whole thread Raw
In response to Re: sql_drop Event Trigger  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Tue, Mar 5, 2013 at 5:37 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> Okay, I added a couple of lines to skip reporting dropped temp schemas,
> and to skip any objects belonging to any temp schema (not just my own,
> note).  Not posting a new version because the change is pretty trivial.
>
> Now, one last thing that comes up is what about objects that don't have
> straight names (such as pg_amop, pg_amproc, pg_default_acl etc etc), the
> only thing you get is a catalog OID and an object OID ... but they are
> pretty useless because by the time you get to the ddl_command_end
> trigger, the objects are gone from the catalog.  Maybe we should report
> *something* about those.  Say, perhaps the object description ... but if
> we want that, it should be untranslated (i.e. not just what
> getObjectDescription gives you, because that may be translated, so we
> would need to patch it so that it only translates if the caller requests
> it)

Broadly, I suggest making the output format match as exactly as
possible what commands like COMMENT and SECURITY LABEL accept as
input.  We've already confronted all of these notational issues there.Columns are identified as COLUMN table.name;
functionsas FUNCTION
 
function_name(argtypes); etc.  Of course it's fine to split the object
type off into a separate column, but it should have the same name here
that it does there.

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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Writable foreign tables: how to identify rows
Next
From: Josh Berkus
Date:
Subject: Re: transforms