Re: [BUGS] [HACKERS] object_classes array is broken, again

2016-11-29 Thread Alvaro Herrera
Alvaro Herrera wrote: > Jaimin Pan wrote: > > Hi all, > > > > How about this patch. I believe it will never missing someone and be > > detected while compiling. > > Hmm, yeah this looks like something that's worth considering going > forward. I can't think of any reason not to do this. Perhaps

Re: [BUGS] [HACKERS] object_classes array is broken, again

2015-07-23 Thread Jaimin Pan
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

Re: [BUGS] [HACKERS] object_classes array is broken, again

2015-07-21 Thread Alvaro Herrera
Jaimin Pan wrote: Hi all, How about this patch. I believe it will never missing someone and be detected while compiling. Hmm, yeah this looks like something that's worth considering going forward. I can't think of any reason not to do this. Perhaps we can write getObjectClass using this,

Re: [BUGS] [HACKERS] object_classes array is broken, again

2015-07-21 Thread Alvaro Herrera
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

Re: [HACKERS] object_classes array is broken, again

2015-07-20 Thread Alvaro Herrera
Any opinions on this idea? I don't like it all that much, but it's plenty effective. Alvaro Herrera wrote: The problem is that there aren't enough callers of add_object_address: there are many indexes of that array that aren't ever accessed and so it's not obvious when the array is broken.

Re: [BUGS] [HACKERS] object_classes array is broken, again

2015-07-20 Thread Tom Lane
Alvaro Herrera alvhe...@2ndquadrant.com writes: Any opinions on this idea? I don't like it all that much, but it's plenty effective. I don't like it much either. What about adding StaticAsserts that lengthof() the relevant constant arrays is equal to MAX_OCLASS? (Or other similar ways of

Re: [BUGS] [HACKERS] object_classes array is broken, again

2015-07-20 Thread Tom Lane
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

Re: [BUGS] [HACKERS] object_classes array is broken, again

2015-07-20 Thread Tom Lane
Alvaro Herrera alvhe...@2ndquadrant.com writes: Tom Lane wrote: What about adding StaticAsserts that lengthof() the relevant constant arrays is equal to MAX_OCLASS? (Or other similar ways of checking that they have the right number of entries.) Well, the array itself is declared like this:

Re: [BUGS] [HACKERS] object_classes array is broken, again

2015-07-20 Thread Alvaro Herrera
Tom Lane wrote: Alvaro Herrera alvhe...@2ndquadrant.com writes: Any opinions on this idea? I don't like it all that much, but it's plenty effective. I don't like it much either. What about adding StaticAsserts that lengthof() the relevant constant arrays is equal to MAX_OCLASS? (Or

Re: [HACKERS] object_classes array is broken, again

2015-07-18 Thread Alvaro Herrera
Robert Haas wrote: The transforms patch seems to have forgotten to add TransformRelationId to object_classes[], much like the RLS patch forgot to add PolicyRelationId in the same place. Fixing this is easy, but ISTM that we need to insert some sort of a guard to prevent people from

Re: [HACKERS] object_classes array is broken, again

2015-06-26 Thread Jim Nasby
On 6/24/15 2:11 PM, Robert Haas wrote: Fixing this is easy, but ISTM that we need to insert some sort of a guard to prevent people from continuing to forget this, because it's apparently quite easy to do. Perhaps add_object_address should Assert(OidIsValid(object_classes[oclass])), plus a

[HACKERS] object_classes array is broken, again

2015-06-24 Thread Robert Haas
The transforms patch seems to have forgotten to add TransformRelationId to object_classes[], much like the RLS patch forgot to add PolicyRelationId in the same place. Fixing this is easy, but ISTM that we need to insert some sort of a guard to prevent people from continuing to forget this,