Re: Last gasp - Mailing list pgsql-hackers

On Thu, 2012-04-05 at 15:30 -0400, Robert Haas wrote:
> On Thu, Apr 5, 2012 at 3:20 PM, Hannu Krosing <hannu@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.

It seemed to me you were coming along nicely with fixing that by adding
the "toplevel", except that the disussion drifted away to solving some
bigger problems of DDL triggering DDL.

> >> - 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.  

Due to fractal nature of programming problems I doubt the "completely
safe" part  ;) 

You (or someone else) would have found a next obscure set of conditions
where specially crafted function and/or schema could wreak havoc
somewhere.

> I don't think it's
> acceptable for it to, say, corrupt the system catalog contents.

Sure, but any C function can do that already, and we have had C UDF-s
from the start.

> >> 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.

I can say it again :)

> >> 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.

I must admit I did check it only occasionally and to me it seemed to
come along nicely.

I really should have started panicking earlier.

> -- 
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>