Re: a misbehavior of partition row movement (?)

On Tue, Jan 18, 2022 at 7:15 AM Alvaro Herrera <alvherre@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