Re: sql_drop Event Trigger - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: sql_drop Event Trigger
Date
Msg-id 20130206034231.GK5753@alvh.no-ip.org
Whole thread Raw
In response to Re: sql_drop Event Trigger  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: sql_drop Event Trigger  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Re: sql_drop Event Trigger  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Dimitri Fontaine escribió:
> And already a v1.
>
> Álvaro did spot a line I did remove by mistake in the docs, and some
> extra whitespace changes that pgindent will change anyway and that as
> such I shouldn't force you to read and discard.

The bigger change I mentioned was the stuff in dependency.c -- I wasn't
too happy about exposing the whole ObjectAddresses stuff to the outside
world.  The attached version only exposes simple accessors to let an
external user of that to iterate on such arrays.  Some more commentary
is probably needed on those new functions.  Also, if we're going to
extend things in this way we probably need to get "extra" out alongside
the object array itself.

A larger issue with the patch is handling of subxacts.  A quick test
doesn't reveal any obvious misbehavior, but having the list of objects
dropped by a global variable might be problematic.  What if, say, the
event trigger function does something funny in an EXCEPTION block and it
fails?  Some clever test case is needed here, I think.  Also, if we
reset the variable at EOXact, do we also need to do something at
EOSubXact?

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

Attachment

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [COMMITTERS] pgsql: Improve concurrency of foreign key locking
Next
From: Pavel Stehule
Date:
Subject: Re: PATCH: Split stats file per database WAS: autovacuum stress-testing our system