Tom Lane wrote: > Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > > Now, it annoys me that we now have three places that know about object > > types supported by event triggers: there's a large struct of command tag > > substrings (event_trigger_support), then there's these two functions. > > It might be better to add ObjectType and ObjectClass entries to the > > struct, so that only the struct needs to know about that. The problem > > is that these two functions would have to walk the struct every time, > > instead of being a simple switch. > > Yeah. For the moment I think efficiency trumps having the information > in just one place, ie I agree with doing it like this. If we find we're > constantly forgetting to fix the functions when we need to, it'd be time > enough to revisit the decision.
Makes sense. > One thing you could do that might make it less likely we'd miss things > is to have the switches explicitly cover all the possible enum members, > instead of defaulting the majority of them as you do here. I know when > I think about adding a new object type, I tend to choose the most > similar existing type and grep for references to it. Likely you could > even draft the code so that most compilers would warn about an enum > value not covered in the switch. I removed the default case, and my compiler is quiet about the current coding and makes noise if I add a new value to the enums. So I guess we're covered. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
