Re: pg_dump gets attributes from tables in extensions

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 ?

On Fri, Feb 20, 2015 at 12:20 PM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com
> wrote:

> On Fri, Feb 20, 2015 at 5:33 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> > On 2/16/15 2:45 AM, Michael Paquier wrote:
> >> While looking at the patch to fix pg_dump with extensions containing
> >> tables referencing each other, I got surprised by the fact that
> >> getTableAttrs tries to dump table attributes even for tables that are
> >> part of an extension. Is that normal?
> >> Attached is a patch that I think makes things right, but not dumping any
> >> tables that are part of ext_member.
> >
> > Can you provide an example/test case? (e.g., which publicly available
> > extension contains tables with attributes?)
>
> Sure. Attached is a simplified version of the extension I used for the
> other patch on pg_dump.
> $ psql -c 'create extension dump_test'
> CREATE EXTENSION
> $ psql -At -c '\dx+ dump_test'
> table aa_tab_fkey
> table bb_tab_fkey
> $ pg_dump -v 2>&1 | grep "columns and types"
> pg_dump: finding the columns and types of table "public"."bb_tab_fkey"
> pg_dump: finding the columns and types of table "public"."aa_tab_fkey"
> --
> Michael
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>

--
Rushabh Lathia