Re: pg_dump gets attributes from tables in extensions

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;