Re: pg_dump doesn't dump new objects created in schemas from extensions

2016-06-16 15:55 GMT-03:00 Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>:
>
> To make the problem worse, the pgq.create_queue() function also inserts
> rows in the pgq.queue table. The pgq.queue table is marked as a
> configuration table, so the rows that reference the pgq.event_1 etc
> tables are dumped, but not the tables themselves.

Exactly. And that's why all the pgq.get_*_info() functions error out
with a missing event table.

> This is pretty messy and I wonder why it hadn't been reported thus far.
> I would argue that those secondary tables should be created in a
> different schema, but then that schema would probably be created by the
> pgq extension script too and would not get dumped either.

I bet that most people load the sql or work with outside processes
like Londiste that creates all the needed functions and tables without
using PgQ as an extension (this is actually the first time I work with
PgQ as an extension, even though I've worked alot with it together
with Londiste.

> So we want the policy to change to "dump the table unless it has a
> dependency on an extension" (rather than "inherit dump flag from
> containing schema). I wonder what other things this change would break.

IMO, this assignment:

tbinfo->dobj.dump = tbinfo->dobj.namespace->dobj.dump_contains;

should be replaced by a call to some new function which would be more
or less a copy of selectDumpableNamespace, but without the
checkExtensionMembership call.

Regards,

--
Martín Marqués http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services