amul sul <sul_a...@yahoo.co.in> writes: > In dumpAttrDef() function we are skipping dump if table definition is not > dumped(i.e. by checking > tbinfo->dobj.dump), its absolutely alright to do this.
> But, in dumpConstraint() we doing same by checking constraint dump > flag(coninfo->dobj.dump) instead of table dump flag(tbinfo->dobj.dump). > IMHO, for a code consistency we should use attribute dump > flag(adinfo->dobj.dump) instead of table dump flag as shown below: I don't see much point in doing it that way, since that code could not possibly work right if the constraint has a different dump flag from the table: it would either omit a required component of the table or emit an ALTER TABLE against a nonexistent table. So this change could not fix any bug, and might introduce some if the flag values weren't carefully kept equal. Note also that the normal "not separate" code path for dumping defaults hasn't got any test on the default's flag, so this would be adding inconsistency compared to that. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers