Re: Fix bug of CHECK constraint enforceability recursion

> * 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")