public inbox for [email protected]  
help / color / mirror / Atom feed
From: Amit Langote <[email protected]>
To: Alvaro Herrera <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Andrew Dunstan <[email protected]>
Cc: Ibrar Ahmed <[email protected]>
Cc: Arne Roland <[email protected]>
Cc: David G. Johnston <[email protected]>
Cc: Masahiko Sawada <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Cc: Rahila Syed <[email protected]>
Cc: Tomas Vondra <[email protected]>
Subject: Re: a misbehavior of partition row movement (?)
Date: Tue, 18 Jan 2022 12:00:45 +0900
Message-ID: <CA+HiwqEEvVwdPmtUsBhBJRfg064V-_sP0DM35MVeDxbA0_iaBQ@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>

On Tue, Jan 18, 2022 at 7:15 AM Alvaro Herrera <[email protected]> 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






view thread (7+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: a misbehavior of partition row movement (?)
  In-Reply-To: <CA+HiwqEEvVwdPmtUsBhBJRfg064V-_sP0DM35MVeDxbA0_iaBQ@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox