On 28/09/26 17:40, Ayush Tiwari wrote:
Attached are:- v2-0001: Nitin's v1, unchanged. - v2-0002: validate re-added domain constraints after the rewrites (issue 1).Thanks, the split looks right to me. On 0002, remembering the new constraint OID and calling validateDomainCheckConstraint() directly is better than what I suggested. Using the OID avoids resolving the domain and constraint by name again in phase 3, and the standalone-composite case needs the new loop not to skip relations without storage. One small thing: the new loop doesn't CommandCounterIncrement() between constraints. Probably fine today, but the FK loop and afterStmts do. And I think 0001 and 0002 can be clubbed together (though that can be done whilst committing)
Thank you for checking the patches. I don't think that the FK loop call CommandCounterIncrement() or I'm missing something? Also I think that afterStmts call it because it use ProcessUtilityForAlterTable, so I don't think that it is required for the new domain constraints loop, but I might be wrong. I'm not sure if these two patches should be squashed into a single one. I see these both issues as separated issues, although the fix on 0001 enable the second issue to happen more easily.
I've only looked closely at 0001 and 0002 so far, which fix the reported case for me across branches. I'll come back on 0003.
Thank you! -- Matheus Alcantara EDB: https://www.enterprisedb.com
