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;
Ok. Looking at above code into getExtensionMembership(). It seems like you fix you suggested is not correct. I new table with DEFAULT attribute into dump_test extension and pg_dump with binary-upgrade is failing with pg_dump: invalid column number 1 for table "bb_tab_fkey".
