Tom Lane wrote:
> Alvaro Herrera <alvherre@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
