On 2025-Apr-07, jian he wrote:
> CREATE TABLE t (a int, b int);
> INSERT INTO t VALUES (NULL, 1), (300, 3);
> ALTER TABLE t ADD CONSTRAINT nn NOT NULL a NOT VALID; -- ok
> ALTER TABLE t add column c float8 default random();
> the last query should not fail.
Agreed.
> if we want more places use CompactAttribute->attnullability
> set_attnotnull should also set CompactAttribute->attnullability proactively
> not waiting CommandCounterIncrement invoke RelationBuildTupleDesc.
Actually, the fix here was to tweak equalTupleDescs to also compare
attnullability, and then ensure that a relcache invalidation happens.
That way the old tupdesc goes away correctly.
I have pushed this after some small additional changes. I ran some of
the tests under debug_discard_caches=1 to make sure that invalidations
are handled correctly also.
I have to admit that this patch was much more difficult than I had
initially anticipated. Thank you Rushabh very much for the effort in
writing and rewriting as the different ideas came and went, and Jian for
the eagle eyes and the additional test cases and debugging.
Cheers
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"In Europe they call me Niklaus Wirth; in the US they call me Nickel's worth.
That's because in Europe they call me by name, and in the US by value!"
