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.)
