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