From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Thom Brown <thom(at)linux(dot)com>, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [BUGS] Breakage with VACUUM ANALYSE + partitions |
Date: | 2016-05-04 14:55:42 |
Message-ID: | 6502.1462373742@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> writes:
>> 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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2016-05-04 16:29:08 | Re: [BUGS] Breakage with VACUUM ANALYSE + partitions |
Previous Message | Chris Pacejo | 2016-05-04 12:09:34 | Re: BUG #14064: Sort order of bytea, etc. not defined |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-05-04 14:58:30 | Re: Make PG's "NOT NULL"s and attnotnull ("is_nullable") conform to SQL-2011 |
Previous Message | Tom Lane | 2016-05-04 14:45:59 | Re: pg_dump broken for non-super user |