Re: Clang compiler warning on 9.3 HEAD

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