Re: Event Triggers: adding information

Robert Haas <robertmhaas@gmail.com> writes:
>> The current patch implementation is to fill in the object id, name and
>> schema with NULL when we have something else than a single object as the
>> target. I did that when I realized we have a precedent with statement
>> triggers and that we would maybe share the implementation of the "record
>> set variable" facility for PLs here.
>
> But I don't see how *that's* going to be any good for logical
> replication either.  If the raw query string isn't useful, getting the
> OID in some cases but not all surely can't be any better.

Well I would think that "we don't support droping several objects at
once yet in 9.3" is an acceptable answer. And for DROP, it's a special
case anyway as what happens is that you *stop* receiving any data from
those tables/objects, so the problem is one of cleanup.

>> So we have two proposals here:
>>
>>   - Have the cascading drop calls back to process utility with a new
>>     context value of PROCESS_UTILITY_CASCADE and its parse node, wherein
>>     you only stuff the ObjectAdress, and provide event triggers support
>>     for this new cascade command;
>>
>>   - Implement a new event called "sql_drop" where you provide the same
>>     amount of information than in a ddl_command event (same lookups,
>>     etc), but without any parsetree nor I suppose the command string
>>     that the user would have to type to drop just that object.
>>
>> You objected to the first on modularity violation grounds, and on the
>> second on development cycle timing grounds. And now you're saying that
>> because we don't have a practical solution, I'm not sure, apparently
>> it's dead, but what is?
>>
>> Please help me decipher your process of thoughs and conclusions.
>
> OK, so I object to the first one on modularity grounds (as did Tom).
> I don't object to the second one at all except that, AFAIK, nobody's
> written the code yet.  Maybe I'm misunderstanding something.

I mean object as in "not in 9.3, too late", which you seem to me
confirming here. So what do we want to provide in 9.3 exactly?

Note that I have enough time allocated on finishing that patch that I
surely can come up with an implementation of whatever we finally decide
within this commit fest, if the implementation is straightforward
enough. As I've been playing in and out around those topics for 2 years
now, plenty of things are a SMOP now: the problem is reaching an
agreement about how to implement things.

> Actually, I think we could probably use a similar set of
> infrastructure *either* to implement sql_drop OR to provide the
> information to ddl_command_end.  What I'm thinking about is that we
> might have something sort of like after-trigger queue that we use for
> ordinary triggers.  Instead of calling a trigger as the drops happen,
> we queue up a bunch of events that say "xyz got dropped".  And then,
> we can either fire something like ddl_command_end (and pass in the
> whole list as an array or a table) or we can call something like
> sql_drop (n times, passing details one one object per invocation).  In
> either approach, the triggers fire *after* the drops rather than in
> the middle of them - it's just a question of whether you want one call
> for all the drops or one call for each drop.

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.

> Well, the point is that if you have a function that maps a parse tree
> onto an object name, any API or ABI changes can be reflected in an
> updated definition for that function.  So suppose I have the command
> "CREATE TABLE public.foo (a int)".  And we have a call
> pg_target_object_namespace(), which will return "public" given the
> parse tree for the foregoing command.  And we have a call
> pg_target_object_name(), which will return "foo".  We can whack around
> the underlying parse tree representation all we want and still not
> break anything - because any imaginable parse tree representation will
> allow the object name and object namespace to be extracted.  Were that
> not possible it could scarcely be called a parse tree any longer.

In my view, we have no DDL operation where we don't want to be able to
get at the Object ID, name and schema of the operation. So while more
complex cases might well require a full function based API, I think a
set of magic variables TG_* for basic information is going to make life
easier for everybody.

Then, more complex cases are left alone in 9.3 and we have whole
development cycle to address them, with some data type and a set of
functions maybe.

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