Re: [BUGS] Breakage with VACUUM ANALYSE + partitions - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: [BUGS] Breakage with VACUUM ANALYSE + partitions
Date
Msg-id alpine.DEB.2.10.1605041750420.30701@sto
Whole thread Raw
In response to Re: [BUGS] Breakage with VACUUM ANALYSE + partitions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [BUGS] Breakage with VACUUM ANALYSE + partitions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hello Tom,

>>> There's not really a point in using an enum if you use neither the type
>>> (which you shouldn't because if you or the bitmask value you have types
>>> outside the range of the enum), nor the autogenerated numbers.
>
>> I do not think that there is such a constraint in C, you can use the enum
>> bitfield type, so you should.
>
> I think you are failing to understand Andres' point.  If you're going
> to OR together some bits, the result is no longer a member of the enum
> type, and the advantages that an enum would have immediately turn into
> disadvantages.

I understood the point and I do not see real disadvantages. The C standard 
really says that an enum is an int, and compilers just do that. I see it 
as a matter of interpretation whether enum members are strictly allowed 
values or just allowed bits, but maybe the standard says otherwise.

Anyway, the good news is that the bug is now fixed.

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: what to revert
Next
From: Alvaro Herrera
Date:
Subject: Re: what to revert