> 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.
Ah okay.
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.
Thank you Alvaro for your support and guidance. Thanks Jian.
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!"
