On 2022-Jan-17, Tom Lane wrote: > But could we please do it in a way that is designed to keep the > code readable, rather than to minimize the number of lines of diff? > It makes zero sense to have the bits in AFTER_TRIGGER_TUP_BITS not > be adjacent. So what should happen here is to renumber the symbols > in between to move their bits over one place.
Is it typical to enumerate bits starting from the right of each byte, when doing it from the high bits of the word? DONE and IN_PROGRESS have been defined as 0x1 and 0x2 of that byte for a very long time and I found that very strange. I am inclined to count from the left, so I'd pick 8 first, defining the set like this: #define AFTER_TRIGGER_OFFSET 0x07FFFFFF /* must be low-order bits */ #define AFTER_TRIGGER_DONE 0x80000000 #define AFTER_TRIGGER_IN_PROGRESS 0x40000000 /* bits describing the size and tuple sources of this event */ #define AFTER_TRIGGER_FDW_REUSE 0x00000000 #define AFTER_TRIGGER_FDW_FETCH 0x20000000 #define AFTER_TRIGGER_1CTID 0x10000000 #define AFTER_TRIGGER_2CTID 0x30000000 #define AFTER_TRIGGER_CP_UPDATE 0x08000000 #define AFTER_TRIGGER_TUP_BITS 0x38000000 (The fact that FDW_REUSE bits is actually an empty mask comes from 7cbe57c34dec, specifically [1]) Is this what you were thinking? [1] https://postgr.es/m/20140306033644.ga3527...@tornado.leadboat.com -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/ "All rings of power are equal, But some rings of power are more equal than others." (George Orwell's The Lord of the Rings)
