Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
>> Really I think there is not any single point where you can put the
>> command-trigger hook and be done. In almost every case, the right
>> place is going to be buried somewhere within the execution of the
>> command.
>
> I'm finally realizing it. I already introduced a structure called
> CommandContextData to keep track of the current command elements we want
> to pass down to command triggers, I think we're saying that this should
> be a static variable that commands will need to be editing.
In fact passing it as an argument to the command trigger API is much
simpler and done in the attached. I'm having problems here with my
install and not enough time this week (you don't speak English if you
don't use understatements here and there, right?) so please expect a
one-step-further patch to show the integration concept, not a ready for
commit one just yet.
Next steps are about adding support for more commands, and now that we
have settled on a simpler integration that will be easy. The parameters
sent to the trigger procedure are now the command tag, the main object
Oid, its schema name and its object name. Only the command tag will
never be NULL, all the other columns could be left out when calling an
ANY COMMAND trigger, or a command on a schemaless object.
Note: the per-command integration means the Oid is generally available,
so let's just export it.
An ack about the way it's now implemented would be awesome, and we could
begin to start about which set of command exactly we want supported from
the get go (default to all of them of course, but well, I don't think
that's necessarily the best use of our time given our command list).
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
