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.paqu...@gmail.com > wrote: > On Fri, Feb 20, 2015 at 5:33 AM, Peter Eisentraut <pete...@gmx.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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > > -- Rushabh Lathia
