Re: Clang compiler warning on 9.3 HEAD

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Will Leinweber <will(at)heroku(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Clang compiler warning on 9.3 HEAD
Date: 2013-04-04 21:52:32
Message-ID: 12541.1365112352@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2013-04-04 21:52:45 matview scannability rehash (was Re: Drastic performance loss in assert-enabled build in HEAD)
Previous Message Jeff Janes 2013-04-04 21:21:19 Re: corrupt pages detected by enabling checksums