> On Jun 6, 2026, at 02:44, Zsolt Parragi <[email protected]> wrote: > >> * It is common for a partitioned table to have thousands of partitions, but >> I rarely hear of a regular inherited table having thousands of descendants. > > Yes, that's why I also wasn't sure if it's needed or not, I can > construct scenarios where alters take a relatively long time, but > those do not seem to be realistic at all... so maybe it's an > acceptable limitation as you said. > >> BTW, do you have any comments on the doc changes in 0002 and 0003? > > + (check and not-null constraints) down the inheritance hierarchy. With > + multiple inheritance, if a column or constraint is inherited from more > + than one parent, the stricter definition applies. > > The documentation changes generally look good to me, but should this > statement be part of the alter table description? There's a paragraph > about merge rules above which might be a better fit for it. > ("Inheritable check constraints and not-null constraints are merged in > a similar fashion") >
Make sense. PFA v8: 0001 and 0003 unchanged. 0002 addressed Zsolt’s comment. Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/
v8-0001-Prevent-inherited-CHECK-constraints-from-being-we.patch
Description: Binary data
v8-0002-doc-Clarify-inherited-constraint-behavior.patch
Description: Binary data
v8-0003-doc-Clarify-ALTER-CONSTRAINT-enforceability-behav.patch
Description: Binary data
