Dimitri Fontaine <dimi...@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
command-trigger.v6.patch.gz
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers