Robert Haas <robertmhaas@gmail.com> writes:
> Huh? AFAICS, there are vestiges of the old terminology all over the
> patch, although some very incomplete renaming has been done. I'm
> pretty sure you haven't made the firing points consistent either,
> although I'd have to spend more time reviewing to be sure of that.
I've choosen to internally have command triggers built in an event
trigger framework, because clearly the only kind of events we have an
idea how to manage are commands here. Don't generalize an API with only
one use case, etc. So internally it's very much command oriented, while
the usage is all about "events".
The firing point didn't move yet, I finished the mechanism. It's now
about picking the right event name for each of them, I've begin to
explore about that in aggregatecmds.c already. So I think that's only a
policy issue now when it was just impossible some days ago.
> I think it's fair to say that there's probably another month of work
> here to get this committed. It is, of course, up to the community as
> a whole whether they want to delay 9.2 another month for this and
> perhaps other patches that are not yet done. But the idea that we're
> going to pull it together into committable form in the next 24 hours
> is not realistic.
All of that depends on what you want to see commit, I'm still under the
illusion that parts of it are going to be salvaged. For example we could
decide to implement "command_start" and "commend_end" in utility.c and
remove all special variables support apart from the parse tree for user
functions written in C. That would already be something.
Of course as I wasn't running for that outcome that's not what you
currently see in the branch.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
