Re: pg_dump gets attributes from tables in extensions

On Mon, Feb 23, 2015 at 7:45 PM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
wrote:

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

rushabh(at)rushabh-centos-vm:dump_test$ cat dump_test--1.0.sql
/* dump_test/dump_test--1.0.sql */

-- complain if script is sourced in psql, rather than via CREATE EXTENSION
\echo Use "CREATE EXTENSION dump_test" to load this file. \quit

CREATE TABLE IF NOT EXISTS bb_tab_fkey (
id int PRIMARY KEY
);

CREATE TABLE IF NOT EXISTS aa_tab_fkey (
id int REFERENCES bb_tab_fkey(id)
);

CREATE TABLE IF NOT EXISTS foo ( a int default 100 );

This gave another strong reason to add if (!tbinfo->dobj.dump) check rather
then ext_member check. What you say ?

Regards,