Re: sql_drop Event Trigger

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, 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-05 21:42:18
Message-ID: 20130305214218.GP9507@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera escribió:

> Hmm, maybe I should be considering a pair of macros instead --
> UTILITY_START_DROP and UTILITY_END_DROP. I'll give this a try. Other
> ideas are welcome.

This seems to work. See attached; I like the result because there's no
clutter and it supports all three cases without a problem.

I also added a new output column to pg_event_trigger_dropped_objects,
"subobject_name", which is NULL except when a column is being dropped,
in which case it contains the column name. Also, the "object type"
column now says "table column" instead of "table" when dropping a
column.

Another question arose in testing: this reports dropping of temp
objects, too, but of course not always: particularly not when temp
objects are dropped at the end of a session (or the beginning of a
session that reuses a previously used temp schema). I find this rather
inconsistent and I wonder if we should instead suppress reporting of
temp objects.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachment Content-Type Size
dropped_objects.7.patch text/x-diff 39.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2013-03-05 21:51:52 Re: Materialized views WIP patch
Previous Message Heikki Linnakangas 2013-03-05 21:26:59 Re: Performance Improvement by reducing WAL for Update Operation