Re: not null constraints, again

static Oid
StoreRelNotNull(Relation rel, const char *nnname, AttrNumber attnum,
                bool is_validated, bool is_local, int inhcount,
                bool is_no_inherit)
{
    Oid            constrOid;
    Assert(attnum > InvalidAttrNumber);
    constrOid =
        CreateConstraintEntry(nnname,
                              RelationGetNamespace(rel),
                              CONSTRAINT_NOTNULL,
                              false,
                              false,
                              is_validated
....
}
is is_validated always true, can we add an Assert on it?


in AddRelationNotNullConstraints
for (int outerpos = 0; outerpos < list_length(old_notnulls); outerpos++)
{
}
CookedConstraint struct already has "int inhcount;"
can we rely on that, rather than using add_inhcount?
we can also add an Assert: "Assert(!cooked->is_no_inherit);"

I've put these points into a patch,
please check the attached.




        /*
         * Remember primary key index, if any.  We do this only if the index
         * is valid; but if the table is partitioned, then we do it even if
         * it's invalid.
         *
         * The reason for returning invalid primary keys for foreign tables is
         * because of pg_dump of NOT NULL constraints, and the fact that PKs
         * remain marked invalid until the partitions' PKs are attached to it.
         * If we make rd_pkindex invalid, then the attnotnull flag is reset
         * after the PK is created, which causes the ALTER INDEX ATTACH
         * PARTITION to fail with 'column ... is not marked NOT NULL'.  With
         * this, dropconstraint_internal() will believe that the columns must
         * not have attnotnull reset, so the PKs-on-partitions can be attached
         * correctly, until finally the PK-on-parent is marked valid.
         *
         * Also, this doesn't harm anything, because rd_pkindex is not a
         * "real" index anyway, but a RELKIND_PARTITIONED_INDEX.
         */
        if (index->indisprimary &&
            (index->indisvalid ||
             relation->rd_rel->relkind == RELKIND_PARTITIONED_TABLE))
        {
            pkeyIndex = index->indexrelid;
            pkdeferrable = !index->indimmediate;
        }
The comment (especially paragraph "The reason for returning invalid
primary keys") is overwhelming.
Can you also add some sql examples into the comments.
I guess some sql examples, people can understand it more easily?