Hi Nitin, I reviewed and tested v1. The fix looks right to me. For a domain constraint, the relation OID in ATPostAlterTypeCleanup() only decides whether another relation gets locked and which work-queue entry gets the AT_ReAddDomainConstraint command. The AlterDomainStmt names the domain itself, so using tab->relid is fine.
Testing (macOS arm64, meson debug build with assertions, master at ad36e3608c plus v1): v1 applies cleanly with git am, and the regression tests pass. I also ran these cases on master and on the patched build. Master fails on all of them with "could not identify relation associated with constraint". With v1 the type change goes through and the constraint is rebuilt: - ALTER TABLE ... ALTER COLUMN ... TYPE on a table whose row type is used in the check of a domain over int - a domain over int[], and a domain over a domain over int - a typed table, with ALTER TYPE ... CASCADE - one domain check that uses both a parent's and a child's row type, with ALTER TABLE on the parent - a table column of the domain type with data in it (the constraint is revalidated) - a comment on the constraint (kept) and a NOT VALID constraint (stays NOT VALID) Where I checked, the rebuilt constraint still rejects bad values. Comments: 1. The bug isn't specific to ALTER TYPE. ALTER TABLE ... ALTER COLUMN ... TYPE hits it too, as in the first case above. I'd add a test for that and mention it in the commit message. 2. The commit message says the domain is "defined over a scalar type". Arrays and domains over domains are affected too, so "a domain whose base type isn't composite" would be more accurate. 3. In the tests, I'd describe the float8 case instead of referring to "Tom Lane's 2017 email". 4. One side effect: for a domain over a different composite type, as in CREATE DOMAIN dd AS r2 CHECK ((ROW((VALUE).b)::r1).a > 0); ALTER TYPE r1 ALTER ATTRIBUTE a TYPE bigint; master takes an AccessExclusiveLock on r2 and queues the rebuild there, while v1 does neither. I think that's fine, since the rebuilt constraint belongs to the domain and doesn't touch r2. 5. af20e2d72 went into v11, so every supported branch has this bug. v1, tests included, applies cleanly to REL_14_STABLE through REL_19_STABLE, so +1 for back-patching. I couldn't find this in the open commitfest (PG20-3). Could you add it? I'm happy to be listed as a reviewer. Regards, Rahul Yadav
