Buildfarm critters friarbird and jaguarundi have been failing for 11
days, apparently due to the sql_drop event for event triggers feature.
These are both FBSD machines, but more importantly are both building
with -DCLOBBER_CACHE_ALWAYS.
Tom complained about it at the time, see
On Tue, Mar 5, 2013 at 5:37 PM, Alvaro Herrera alvhe...@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.
Alvaro Herrera alvhe...@2ndquadrant.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,
On Mon, Mar 4, 2013 at 11:13 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Another question. If I do ALTER TABLE foo DROP COLUMN bar, do we need
to fire an event trigger for the dropped column? Right now we don't,
ISTM we should. And if we want that, then the above set of three
On Mon, Mar 4, 2013 at 4:59 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Alvaro Herrera escribió:
I think this is mostly ready to go in. I'll look at your docs, and
unless there are more objections will commit later or early tomorrow.
Actually it still needs a bit more work: the error
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
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
Alvaro Herrera escribió:
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
Dimitri Fontaine escribió:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Do we want some more stuff provided by pg_dropped_objects? We now have
classId, objectId, objectSubId, object name, schema name. One further
thing I think we need is the object's type, i.e. a simple untranslated
Alvaro Herrera alvhe...@2ndquadrant.com writes:
I'm very unsure about that idea. In any case the proposed name seems
way too general. Maybe we could have a separate datatype for objects
being dropped, which would be specific to
pg_event_trigger_dropped_objects(), and not try to mix it with
Dimitri Fontaine escribió:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Another question. If I do ALTER TABLE foo DROP COLUMN bar, do we need
to fire an event trigger for the dropped column? Right now we don't,
ISTM we should. And if we want that, then the above set of three
Dimitri Fontaine escribió:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Do we want some more stuff provided by pg_dropped_objects? We now have
classId, objectId, objectSubId, object name, schema name. One further
thing I think we need is the object's type, i.e. a simple untranslated
Alvaro Herrera escribió:
I think this is mostly ready to go in. I'll look at your docs, and
unless there are more objections will commit later or early tomorrow.
Actually it still needs a bit more work: the error messages in
pg_event_trigger_dropped_object need to be reworked. It's a bit
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Dimitri Fontaine escribió:
The good news is that the patch to do that has already been sent on this
list, and got reviewed in details by Álvaro who did offer incremental
changes. Version 3 of that patch is to be found in:
Dimitri Fontaine escribió:
The good news is that the patch to do that has already been sent on this
list, and got reviewed in details by Álvaro who did offer incremental
changes. Version 3 of that patch is to be found in:
http://www.postgresql.org/message-id/m2fw19n1hr@2ndquadrant.fr
Robert Haas escribió:
On Thu, Feb 21, 2013 at 12:52 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
One funny thing I noticed is that if I add a column in a table being
dropped, the targetObjects list does not change after the trigger has
run. The reason for this is that the table's
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Robert Haas escribió:
I venture to guess that this is exactly the sort of thing that made
Tom argue upthread that we shouldn't be putting a firing point in the
middle of the drop operation. Any slip-ups here will result in
corrupt catalogs, and
On Thu, Feb 28, 2013 at 2:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Robert Haas escribió:
I venture to guess that this is exactly the sort of thing that made
Tom argue upthread that we shouldn't be putting a firing point in the
middle of the
Tom Lane escribió:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Robert Haas escribi�:
I venture to guess that this is exactly the sort of thing that made
Tom argue upthread that we shouldn't be putting a firing point in the
middle of the drop operation. Any slip-ups here will result
Robert Haas escribió:
On Thu, Feb 28, 2013 at 2:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Maybe down the road we'll conclude that there's no other way and we're
willing to put up with an unsafe feature, but I don't want to take that
step
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Robert Haas escribió:
It seems to me that a better way to do this might be to look up the
names of all the objects being dropped, as we get rid of them, and
pass that information off to the ddl_command_end trigger via something
like the
Tom Lane t...@sss.pgh.pa.us writes:
I think it's fairly obvious that
(1) dealing with a DROP only after it's happened is pretty limiting;
(2) allowing user-defined code to run mid-command is dangerous.
What's at issue is the tradeoff we make between these inescapable
facts, and I'm not sure
Dimitri Fontaine escribió:
Tom Lane t...@sss.pgh.pa.us writes:
I think it's fairly obvious that
(1) dealing with a DROP only after it's happened is pretty limiting;
(2) allowing user-defined code to run mid-command is dangerous.
What's at issue is the tradeoff we make between these
On Thu, Feb 28, 2013 at 3:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think it's fairly obvious that
(1) dealing with a DROP only after it's happened is pretty limiting;
(2) allowing user-defined code to run mid-command is dangerous.
What's at issue is the tradeoff we make between these
On Thu, Feb 21, 2013 at 12:47 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
You're misunderstanding. If you do DROP EVENT TRIGGER, the DDL_DROP
event won't fire at all. So no matter how messed up your system is, you
can always fix it by simply dropping the event trigger.
What I was
On Thu, Feb 21, 2013 at 12:52 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
What if the object that gets whacked around is one of the named
objects rather than some dependency thereof? Suppose for example that
the event trigger drops the same object that the user tried to drop.
We need
On Wed, Feb 20, 2013 at 10:48 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
I have added some protections so that these do not fire on undesirable
events (such as dropping an event trigger); also event triggers and
other object types are filtered out of pg_dropped_objects, in case
On Thu, Feb 21, 2013 at 12:25 PM, Robert Haas robertmh...@gmail.com wrote:
There's also code to re-obtain the list of objects to drop after the
event trigger functions have run; the second list is compared to the
first one, and if they differ, an error is raised.
This is definitely an
Robert Haas escribió:
On Wed, Feb 20, 2013 at 10:48 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
I have added some protections so that these do not fire on undesirable
events (such as dropping an event trigger); also event triggers and
other object types are filtered out of
Robert Haas escribió:
On Thu, Feb 21, 2013 at 12:25 PM, Robert Haas robertmh...@gmail.com wrote:
There's also code to re-obtain the list of objects to drop after the
event trigger functions have run; the second list is compared to the
first one, and if they differ, an error is raised.
Robert Haas robertmh...@gmail.com writes:
Well, there's this, upon which we surely have not achieved consensus:
http://www.postgresql.org/message-id/ca+tgmobq6ngsxguihwqcygf0q+7y9zhnerepo3s1vswkknw...@mail.gmail.com
Sub-Transaction Handling. I fail to come up with a regression test
showing any
On Sun, Feb 17, 2013 at 4:12 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Well, a list of object OIDs is of exactly zero use once the command
has been carried out. So I don't think that that represents a useful
or even very testable feature on its own, if there's no provision to
fire
On Thu, Feb 14, 2013 at 3:39 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
Wait, I'm confused. I had a note to myself to come back and review
this, but now that I look at it, I didn't think that patch was pending
review. Alvaro, Tom, and I all
On Mon, Feb 11, 2013 at 9:53 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
Robert, you specifically opposed to sql_drop and I just removed it
from the patch. What do you think now? Also, should that be a follow-up
patch to the current one for your
Robert Haas robertmh...@gmail.com writes:
Wait, I'm confused. I had a note to myself to come back and review
this, but now that I look at it, I didn't think that patch was pending
review. Alvaro, Tom, and I all made comments that seems to impinge
upon that design rather heavily. No?
The
Robert Haas robertmh...@gmail.com writes:
Robert, you specifically opposed to sql_drop and I just removed it
from the patch. What do you think now? Also, should that be a follow-up
patch to the current one for your reviewing purposes?
Well, if it has a different firing point than
Alvaro Herrera alvhe...@2ndquadrant.com writes:
I thought there was the idea that the list of objects to drop was to be
acquired before actually doing the deletion; so that the trigger
function could, for instance, get the name of the table being dropped.
I don't see that it works if we only
Alvaro Herrera alvhe...@2ndquadrant.com writes:
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
Dimitri Fontaine escribió:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
I thought there was the idea that the list of objects to drop was to be
acquired before actually doing the deletion; so that the trigger
function could, for instance, get the name of the table being dropped.
I
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Well, I don't necessarily suggest that. But how about something like
this in performMultipleDeletions:
[edited snippet of code]
/* invoke sql_drop triggers */
EventTriggerSQLDrop();
/*
Dimitri Fontaine escribió:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Well, I don't necessarily suggest that. But how about something like
this in performMultipleDeletions:
[edited snippet of code]
/* invoke sql_drop triggers */
EventTriggerSQLDrop();
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Hmm, quoth
http://www.postgresql.org/message-id/23345.1358476...@sss.pgh.pa.us :
I'd really like to get to a point where we can
define things as happening like this:
* collect information needed to interpret the DDL command
On Tue, Feb 5, 2013 at 10:42 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
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
Robert Haas robertmh...@gmail.com writes:
variable, it seems like there are a number of ways this can go wrong.
Yeah, I think the current behavior might be surprising.
I have not tested the actual behavior of the latest patch, but I think
we want to define things so that the
On Wed, Feb 6, 2013 at 9:36 AM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
variable, it seems like there are a number of ways this can go wrong.
Yeah, I think the current behavior might be surprising.
I have not tested the actual behavior of the
Dimitri Fontaine escribió:
Robert Haas robertmh...@gmail.com writes:
I have not tested the actual behavior of the latest patch, but I think
we want to define things so that the
pg_event_trigger_dropped_objects() function returns, specifically, the
list of objects dropped by the command
Robert Haas robertmh...@gmail.com writes:
I disagree with that. I don't see why the enclosing event trigger
shouldn't be aware of all the objects dropped by the command that just
ran to completion, *including* the effects of any event trigger fired
recursively or not.
Well, that could result
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
I thought there was the idea that the list of objects to drop was to be
acquired before actually doing the deletion; so that the trigger
function could, for instance, get the name of the table being
Tom Lane t...@sss.pgh.pa.us writes:
I might be forgetting something, but doesn't dependency.c work by first
constructing a list of all the objects it's going to drop, and only then
dropping them? Could we inject a pre deletion event trigger call at
the point where the list is completed?
What
Dimitri Fontaine escribió:
Tom Lane t...@sss.pgh.pa.us writes:
I might be forgetting something, but doesn't dependency.c work by first
constructing a list of all the objects it's going to drop, and only then
dropping them? Could we inject a pre deletion event trigger call at
the point
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Dimitri Fontaine escribió:
Tom Lane t...@sss.pgh.pa.us writes:
I might be forgetting something, but doesn't dependency.c work by first
constructing a list of all the objects it's going to drop, and only then
dropping them? Could we inject a
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
I might be forgetting something, but doesn't dependency.c work by first
constructing a list of all the objects it's going to drop, and only then
dropping them? Could we inject a pre deletion event trigger call
Tom Lane t...@sss.pgh.pa.us writes:
Well, a list of object OIDs is of exactly zero use once the command
has been carried out. So I don't think that that represents a useful
or even very testable feature on its own, if there's no provision to
fire user code while the OIDs are still in the
On Wed, Feb 6, 2013 at 9:44 AM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
I disagree with that. I don't see why the enclosing event trigger
shouldn't be aware of all the objects dropped by the command that just
ran to completion, *including* the
On Wed, Feb 6, 2013 at 11:04 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
I thought there was the idea that the list of objects to drop was to be
acquired before actually doing the deletion; so that the
On Wed, Feb 6, 2013 at 12:05 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Feb 6, 2013 at 9:44 AM, Dimitri Fontaine dimi...@2ndquadrant.fr
wrote:
Robert Haas robertmh...@gmail.com writes:
I disagree with that. I don't see why the enclosing event trigger
shouldn't be aware of all the
On Wed, Feb 6, 2013 at 11:30 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Dimitri Fontaine escribió:
Tom Lane t...@sss.pgh.pa.us writes:
I might be forgetting something, but doesn't dependency.c work by first
constructing a list of all
On Wed, Feb 6, 2013 at 12:28 PM, Christopher Browne cbbro...@gmail.com wrote:
On Wed, Feb 6, 2013 at 12:05 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Feb 6, 2013 at 9:44 AM, Dimitri Fontaine dimi...@2ndquadrant.fr
wrote:
Robert Haas robertmh...@gmail.com writes:
I disagree with
On Mon, Feb 4, 2013 at 11:59 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Thanks. Agreed that we will have more of them. In the attached version 3
of the patch, it got renamed to pg_event_trigger_dropped_objects().
Works for me.
With this approach, there's no real need to introduce a
Robert Haas robertmh...@gmail.com writes:
Well, having spent a year or more trying to convince you that we need
sql_drop - mostly because of the complexities of passing an array of
arguments to the trigger function - I now think we don't, because the
pg_event_trigger_dropped_objects() bit
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.
It's a 3 lines change set from before.
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Robert Haas escribió:
On Mon, Feb 4, 2013 at 11:59 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Thanks. Agreed that we will have more of them. In the attached version 3
of the patch, it got renamed to pg_event_trigger_dropped_objects().
Works for me.
With this approach, there's
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
Robert Haas robertmh...@gmail.com writes:
Taking a first look at this, I think the idea of pg_dropped_objects()
is really pretty clever. I like it. I assure we will end up with
several functions of this type eventually, so it might be good to
adopt some kind of distinguishing naming
On Wed, Jan 30, 2013 at 12:59 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
So please find attached to this email an implementation of the sql_drop
event trigger, that refrains on exposing any new information to the
users.
Already a v1 of
Hi,
I took the liberty to create a new thread for $subject, because the main
comments I've been receiving about Event Triggers at this point is how
difficult it is to try and follow our discussions about them.
In order for everybody interested to be able to easily get the important
bits of
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
So please find attached to this email an implementation of the sql_drop
event trigger, that refrains on exposing any new information to the
users.
Already a v1 of that patch, per comments from Álvaro I reuse the
ObjectAddresses facility rather
67 matches
Mail list logo
