Re: a misbehavior of partition row movement (?)
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Amit Langote <amitlangote09@gmail.com>,
Andrew Dunstan <andrew@dunslane.net>,
Ibrar Ahmed <ibrar.ahmad@gmail.com>, Arne Roland <A.Roland@index.de>,
"David G. Johnston" <david.g.johnston@gmail.com>,
Masahiko Sawada <sawada.mshk@gmail.com>,
Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>,
Rahila Syed <rahilasyed90@gmail.com>,
Tomas Vondra <tomas.vondra@2ndquadrant.com>
Date: 2022-01-17T23:11:22Z
Lists: pgsql-hackers
Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > On 2022-Jan-17, Tom Lane wrote: >> 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: Doesn't matter to me either way, as long as the values look like they were all defined by the same person ;-) > (The fact that FDW_REUSE bits is actually an empty mask comes from > 7cbe57c34dec, specifically [1]) That seemed a bit odd to me too, but this is not the patch to be changing it in, I suppose. regards, tom lane
Commits
-
Enforce foreign key correctly during cross-partition updates
- ba9a7e392171 15.0 landed
-
Create foreign key triggers in partitioned tables too
- f4566345cf40 15.0 landed