On 2025/5/21 18:44, jian he wrote:
hi. attached patch is for $subject implementation per https://www.postgresql.org/docs/current/sql-alterdomain.html """ Although ALTER DOMAIN ADD CONSTRAINT attempts to verify that existing stored data satisfies the new constraint, this check is not bulletproof, because the command cannot “see” table rows that are newly inserted or updated and not yet committed. If there is a hazard that concurrent operations might insert bad data, the way to proceed is to add the constraint using the NOT VALID option, commit that command, wait until all transactions started before that commit have finished, and then issue ALTER DOMAIN VALIDATE CONSTRAINT to search for data violating the constraint. """ Obviously, the above behavior can also happen to not-null constraints. add NOT NULL NOT VALID is good for validation invalid data too. the not valid information is displayed at column "Nullable" for example: \dD things List of domains Schema | Name | Type | Collation | Nullable | Default | Check --------+--------+---------+-----------+--------------------+---------+-------------------- public | things | integer | | not null not valid | | CHECK (VALUE < 11)
It makes sense to support the "NOT NULL NOT VALID" option. The two if statements in the AlterDomainNotNull() should be adjusted. if (typTup->typnotnull == notNull && !notNull) ==> if (!notNull && !typTup->typnotnull) if (typTup->typnotnull == notNull && notNull) ==> if (notNull && typTup->typnotnull) -- Quan Zongliang
