Hi all, How about this patch. I believe it will never missing someone and be detected while compiling.
2015-07-21 19:38 GMT+08:00 Alvaro Herrera <alvhe...@2ndquadrant.com>: > Tom Lane wrote: > > I wrote: > > > +1 to this patch, in fact I think we could remove MAX_OCLASS altogether > > > which would be very nice for switch purposes. > > > > Oh, wait, I forgot that the patch itself introduces another reference to > > MAX_OCLASS. I wonder though if we should get rid of that as an enum > value > > in favor of #define'ing a LAST_OCLASS macro referencing the last enum > > item, or some other trick like that. It's certainly inconvenient in > > event_trigger.c to have a phony member of the enum. > > Yeah, that works well enough. Pushed that way. > > > Are there any other arrays that need such tests? > > I looked around with this: > > git grep 'const.*\[.*[^][0-9].*\].*=.*{' > > and found one suspicious-looking use of MAX_ACL_KIND which we could > perhaps define in a way equivalent to what we've done here. We also > have RM_MAX_ID in a couple of arrays but that looks safe because both > the values and the arrays are auto-generated. > > We also have MAX_TIME_PRECISION, MAX_TIMESTAMP_PRECISION, > MAX_INTERVAL_PRECISION, MAXDATEFIELDS, KeyWord_INDEX_SIZE, but these > don't look likely to actually cause any trouble. > > (There are many arrays sized to numerical constants, but there are about > 5000 of those and I'm not in a hurry to verify how they are used.) > > -- > Álvaro Herrera http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >
fix.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers