Re: Command Triggers, patch v11

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I think we had better look seriously at postponing this patch to 9.3.

I understand why you're drawing that conclusion, but I don't think
that's the best we can do here, by a long shot.

> Your reviewing is obviously moving things forward rapidly, but I think
> it's unrealistic to think this is going to be in a committable state
> any time in the next week or two.

What's happening is that I've been abusing Thom's availability, leaving
him with the testing and fixing oddities along the way. Those came
mainly from an attempt at being as automatic as possible when writing
commands support. I'm now about done reviewing each and every call site
and having them covered in the tests.

What remains to be done now is how to pass down arguments to the
triggers (switching from function arguments to trigger style magic
variables, per Tom request), and review REINDEX and CREATE OPERATOR
CLASS support. That's about it.

The API and the call sites location have been stable for a long time
now, and are following your previous round of review. The catalog
storage and commands grammar are ok too, we've been hashing them out.
We've been very careful about not introducing code path hazards, the
only novelty being a new place to ERROR out (no fancy silent utility
command execution control).

Really, I would think we're about there now. I would be rather surprised
not to be able to finish that patch by the end of next week, and will
arrange myself to be able to devote more time on it each day if that's
what needed.

Remember that we intend to build an extension providing a C-coded
function doing the heavy lifting of back parsing the command string from
the Node parse tree, with the goal of having Slony, Londiste and Bucardo
able to use that and implement support for DLLs. I really want that to
happen in 2012.

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