Re: sql_drop Event Trigger

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: sql_drop Event Trigger
Date: 2013-03-07 09:54:27
Message-ID: m2zjyf7cx8.fsf@2ndQuadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Here's another idea --- have three columns, "type", "schema" (as in the
> current patch and as shown above), and a third one for object identity.
>
> For tables and other objects that have simple names, the identity would
> be their names. For columns, it'd be <tablename>.<columnname>. For
> functions, it'd be the complete signature. And so on.

Sounds very good as an extra column yes.

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 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; functions as 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.

I would like the format to be easily copy/paste'able to things such as
regclass/regtype/regprocedure casts, and apparently the COMMENT input
format seems to be the same as that one, so +1 from me.

--
Dimitri Fontaine 06 63 07 10 78
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2013-03-07 10:41:42 Re: 9.2.3 crashes during archive recovery
Previous Message Kohei KaiGai 2013-03-07 09:09:37 Re: Writable foreign tables: how to identify rows