Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
