On Thu, Apr 5, 2012 at 3:20 PM, Hannu Krosing <ha...@krosing.net> wrote: > For me it would be enough to know if the trigger is fired by top-level > command or not.
Well, you would have been out of luck, then. >> - The patch isn't safe if the triggers try to execute DDL on the >> object being modified. It's not exactly clear what misbehavior will >> result in every case, but it is clear that that it hasn't really been >> thought about. > > It never seemed important for me, as the only thing I was ever expecting > to do in a command trigger was inserting rows in one unrelated table. > > To me DDL-triggered-by-DDL seemed like a very bad idea anyway. > > But as you seemed to be envisioning some use-cases for that I did not > object to you working it out. Whether or not it works is one thing. I think it's acceptable for it to not do anything useful, although actually I think that given a week to work on it I could make it to completely safe. I don't think it's acceptable for it to, say, corrupt the system catalog contents. >> Now, if anyone who was actually following the conversation thought >> these things were not problems, they could have written back to the >> relevant thread and said, hey, I don't mind if the trigger firing >> behavior changes every time someone does any refactoring of our >> badly-written DDL code and if the server blows up in random ways when >> someone does something unexpected in the trigger that's OK with me >> too. > > I don't mind if the trigger firing behavior changes every time someone > does any refactoring of our badly-written DDL code > > Here :) Duly noted, but color me unconvinced. >> Maybe not surprisingly, no one said that. Two people wrote into >> that thread after my latest round of reviewing and both of them >> disagreed with only minor points of my review, and we had a technical >> discussion about those issues. But showing up after the fact and >> acting as if there were no serious issues found during that review is >> either disingenuous or a sign that you didn't really read the thread. > > As there are other ways to blow up the backend, i did not object to you > either working out a better solution or leaving it as it is. > > I am speaking up now as this is the first time I am told I have to wait > another year for this feature to arrive. Really? You've never seen a patch punted to the next release before because it wasn't robust enough? Considering that I see your name mentioned in the 8.2 release notes, I find that a bit hard to believe. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
