On 2025-Sep-12, Noah Misch wrote: > The last argument gives the dump object on which the comment has a dependency. > Since this is the case of a separately-dumped constraint, the comment needs to > depend on that constraint (coninfo), not on the domain (tyinfo): > > - coninfo->dobj.catId, 0, > tyinfo->dobj.dumpId); > + coninfo->dobj.catId, 0, > coninfo->dobj.dumpId); > > I didn't encounter a failure from this, but sufficient restore parallelism > might reach a failure. A failure would look like a "does not exist" error in > the COMMENT command, due to the constraint not yet existing. > dumpTableConstraintComment() is an older case that optimally handles the last > dumpComment() arg.
Sounds sane. > In the absence of objections, I'll make it so. Please do, thanks. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
