Re: Event Triggers: adding information

Robert Haas <robertmhaas@gmail.com> writes:
>> Well I would think that "we don't support droping several objects at
>> once yet in 9.3" is an acceptable answer.
>
> On that point, I disagree.

Ok, will provide a patch for that soon, then. I did give higher priority
to exposing more information, ok to switch. Read some more for caveats.

> I don't really know how to respond to this.  The CommitFest time is
> supposed to be when you stop working on your own stuff and work on
> reviewing other people's stuff, and yet, both this year and last year,
> you seem to have no compunctions whatever about continuing to code
> right through the CommitFest, which to me misses the point.  The

You might realize that I'm not a commiter, so commit fest is when I get
some review and a chance to react quickly so that we get enough momentum
to reach a consensus and maybe commit something. Also, it seems to me
that I've been very careful to review as many patches as I could in all
commit fests where I had a patch involved.

Also, please consider that if I only allowed myself to write code in
between commit fests, I would still have zero patches in PostgreSQL.
None. Zilch.

> CommitFest, and especially the last one, is supposed to be the time to
> commit what is committable now, not to go write new code.  And it is
> not as if I didn't make these same design points last year around this
> time.

Well, a commit fest for me is the only time when we can reach a common
design, call it a consensus and have matching code to evaluate and maybe
commit. And it's not like if I didn't rewrite this patch series several
times already from scratch to follow your design reviews.

The points where I didn't rewrite the code to match your ideas are those
that I didn't give priority to, or for which I still think my proposal
is better than yours, and so we didn't get to a consensus yet. It seems
to me to be a pretty normal state of affairs, and again, if I am to
follow your advice and never come up with new code while a commit fest
is in progress, I'd better just stop trying to contribute to PostgreSQL.

>> So, do you want to see a patch implementing that to be able to provide
>> information about DROP commands targeting more than one object and same
>> information in other cases (object id, name, schema, operation name,
>> object type)? That could be the next patch of the series, by Thursday.
>
> I think this is approximately correct as a next logical step, but are
> we really clear on what the design for that looks like?  I thought you
> were saying upthread that you wanted to make this information
> available via some kind of pseudo-table for 9.4.  In any event, adding
> a new event type (sql_drop) is a separate patch, and adding
> information to the existing types of event triggers is a separate
> patch, so you should try to do one of those two, not both.

That's exactly what I've been saying too from the beginnings, argueing
that the first step should be providing enough information to user
functions called by event triggers.

If I'm to provide a solution for the multiple object drops without any
specific information associated with firing a trigger, I don't much see
the point of the exercise.

So in my view, either we have specific information and a proper DROP
CASCADE support, or only specific information without support for
multiple DROP targets, or both of them.

Support for CASCADE with no information about the objects being DROPed?
Why would we want that?

> Doing some of it one way and some of it the other way seems kind of
> grotty, though.

It's only following existing design:
 http://www.postgresql.org/docs/9.2/static/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING
 39.6.6.1. Obtaining information about an error
 There are two ways to get information about the current exception in PL/pgSQL: special variables and the GET STACKED
DIAGNOSTICScommand.
 

And I think that having special variables for the most common cases (ID,
name, schema) and a more complex API (later) for more complex cases only
makes sense. And in 9.3, for the most complex cases, you will need to
code your Event Trigger in C and walk the parse tree.

What's wrong with that, in details?

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support