On 2023-Apr-09, Tom Lane wrote: > In the new dispensation, pg_dump omits the NOT NULL clauses. > Great, you say, that makes the output more like what the user wrote. > I'm not so sure. This means that the ALTER TABLE will be compelled > to perform a full-table scan to verify that there are no nulls in the > already-loaded data before it can add the missing NOT NULL constraint.
Yeah, I agree that this unintended consequence isn't very palatable. I think the other pg_upgrade problem is easily fixed (haven't tried yet), but having to rethink the pg_dump representation would likely take longer than we'd like. > I'm inclined to think that this idea of suppressing the implied > NOT NULL from PRIMARY KEY is a nonstarter and we should just > go ahead and make such a constraint. Another idea could be for > pg_dump to emit the NOT NULL, load data, do the ALTER ADD PRIMARY > KEY, and then ALTER DROP NOT NULL. I like that second idea, yeah. It might be tough to make it work, but I'll try. > In any case, I wonder whether that's the sort of redesign we should > be doing post-feature-freeze. It might be best to revert and try > again in v17. Yeah, sounds like reverting for now and retrying in v17 with the discussed changes might be better. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "La espina, desde que nace, ya pincha" (Proverbio africano)