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.
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.
regards, tom lane