Hi, On 2016-05-03 07:24:46 +0200, Fabien COELHO wrote: > >>I'm unsure about switching enum to #define, could be an enum still with > >>explicit values set, something like: > > > >An enum doesn't have a benefit for a bitmask imo - you can't "legally" > >use it as a type for functions accepting the bitmask. > > I do not understand. I suggested to use enum to enumerate the bitmask > constants, ISTM that it does not preclude to use it as a bitmask as you do, > it is just a replacement of the #define? The type constraint on the enum > does not disallow bitmasking values, I checked with both gcc & clang.
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. Anyway seems fairly unimportant. > >>I'm fuzzy about the _OPEN_DELETED part because it is an oxymoron. Is it > >>RECREATE really? > > > >No. The relevant explanation is at the top of the file: > > [...] > > >* -- Optionally, any number of inactive segments of size 0 blocks. > >* Inactive segments are those that once contained data but are currently > >* not needed because of an mdtruncate() operation. The reason for leaving > >* them present at size zero, rather than unlinking them, is that other > >* backends and/or the checkpointer might be holding open file references > >to > >* such segments. If the relation expands again after mdtruncate(), such > >* that a deactivated segment becomes active again, it is important that > >* such file references still be valid --- else data might get written > >* out to an unlinked old copy of a segment file that will eventually > >* disappear. > > Ok. > > Then should it be _OPEN_INACTIVE[TED] or _OPEN_TRUNCATED rather than > _OPEN_DELETED, which is contradictory? Well, TRUNCATED doesn't entirely work, there's I think some cases where this currently also applies to deleted relations. I kind of like the unintuitive sounding name, because it's really a dangerous options (any further mdnblocks will be wrong). Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
