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)