Re: [BUGS] Breakage with VACUUM ANALYSE + partitions

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

In response to

Responses

Browse pgsql-bugs by date

  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

Browse pgsql-hackers by date

  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