On Mon, Feb 23, 2015 at 5:57 PM, Rushabh Lathia <
rushabh.lathia@gmail.com> 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
