On Tue, Jan 18, 2022 at 7:15 AM Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: > 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
Agree that the ultimate code readability trumps diff minimalism. :-) Would you like me to update the patch with the above renumbering or are you working on a new version yourself? -- Amit Langote EDB: http://www.enterprisedb.com
