On Tue, Feb 24, 2015 at 3:13 PM, Rushabh Lathia <rushabh.lat...@gmail.com> wrote: > > 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". >
This problem is not the object of this patch, but the one reported by Gilles Darold here: http://www.postgresql.org/message-id/54b7a400.4020...@dalibo.com And there are patches traded in this CF to solve this issue. > rushabh@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 ? > Nope. Using dobj.dump is a bad idea as well, I think that this would break the tracking of inherit tables and their parent relations, aka the relations that are marked as interesting to track and from which we need attribute information. Btw, perhaps you may have noticed, but I marked this patch as rejected... I don't think it makes much sense to put restrictions in this code path after finding my way through all the stuff of pg_dump. -- Michael
