<div dir="ltr"><br /><br />On Mon, Feb 23, 2015 at 5:57 PM, Rushabh Lathia <<a
href="mailto:rushabh.lathia@gmail.com">rushabh.lathia@gmail.com</a>>wrote:<br />> Thanks to the easy handy
testcase,was able to replicate the test scenario<br />> on my local environment. And yes tbinfo->dobj.ext_member
checkinto<br />> getTableAttrs() do fix the issue.<br />><br />> Looking more into pg_dump code what I found
that,generally PG don't have<br />> tbinfo->dobj.ext_member check to ignore the object. Mostly we do this kind<br
/>>of check using tbinfo->dobj.dump (look at dumpTable() for reference). Do you<br />> have any particular
reasonif choosing dobj.ext_member over dobj.dump ?<br /><br />Hm. I have been pondering about this code more and I am
droppingthe patch as either adding a check based on the flag to track dumpable objects or ext_member visibly breaks the
logicthat binary upgrade and tables in extensions rely on. Particularly this portion makes me think so in
getExtensionMembership():<br/> /*<br /> * Normally, mark the member object as not to be
dumped. But in<br /> * binary upgrades, we still dump the members individually, since the<br />
* idea is to exactly reproduce the database contents rather than<br /> * replace the extension
contentswith something different.<br /> */<br /> if (!dopt->binary_upgrade)<br />
dobj->dump = false;<br /> else<br /> dobj->dump =
refdobj->dump;<br/>Regards,<br />-- <br />Michael</div>