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

Attachment: fix.patch
Description: Binary data

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to