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
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 :
> 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 switc
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
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 en
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
Alvaro Herrera 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:
> static co
Tom Lane wrote:
> Alvaro Herrera 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 wa
Alvaro Herrera 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 checking
that they have th
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
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 con
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 (stati
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, because
12 matches
Mail list logo
