On 2020-10-03 08:40, Peter Eisentraut wrote:
> Since we have ADD PRIMARY KEY USING INDEX, we can declare a primary key
> for an existing index. So this doesn't have to affect the low-level
> early bootstrapping. The attached patch adds those commands manually.
> Another option might be to have the catalog generation Perl tooling
> create those declarations automatically from some marker in the catalog
> files. That would also allow declaring unique constraints for the
> unique indexes that don't end up being the primary key.
I have reworked my patch like this. Now, the primary key is identified
by using DECLARE_UNIQUE_INDEX_PKEY() instead of DECLARE_UNIQUE_INDEX()
in the catalog pg_*.h files. This automatically generates the required
ALTER TABLE commands in a new file system_constraints.sql. initdb is
ordered so that that file is run before dependency processing, so the
system constraints also end up pinned (as was requested during previous
discussion).
Note, this needs the get_constraint_index() patch I just posted
separately. The old implementation of get_constraint_index() does not
handle pinned constraints.
There is something strange going on in the misc_sanity test, as seen by
the test output change
-NOTICE: pg_constraint contains unpinned initdb-created object(s)
This previously detected some constraints from the information schema,
so it was correct to point those out. But since it looks for the
min(oid) of a catalog, this will now find one of the new pinned
constraints, so it won't detect this case anymore. I think that test is
not written correctly.
--
Peter Eisentraut
2ndQuadrant, an EDB company
https://www.2ndquadrant.com/