Re: pg_dump gets attributes from tables in extensions

On Tue, Feb 24, 2015 at 3:13 PM, Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)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.4020805@dalibo.com
And there are patches traded in this CF to solve this issue.

> 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 ?
>

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