Re: a misbehavior of partition row movement (?)

On Tue, Jan 18, 2022 at 7:15 AM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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