From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: sql_drop Event Trigger |
Date: | 2013-02-06 03:42:31 |
Message-ID: | 20130206034231.GK5753@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 | Content-Type | Size |
---|---|---|
dropped_objects.2.patch | text/x-diff | 20.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2013-02-06 06:31:50 | Re: PATCH: Split stats file per database WAS: autovacuum stress-testing our system |
Previous Message | Alvaro Herrera | 2013-02-06 03:30:26 | Re: [COMMITTERS] pgsql: Improve concurrency of foreign key locking |