Re: PgQ and pg_dump

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Martín Marqués <martin(at)2ndquadrant(dot)com>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: PgQ and pg_dump
Date: 2016-06-16 03:08:59
Message-ID: CAB7nPqRjoQfUWcF3L_pm+wHYLpkbmkc+pLoca6XXS3X28BeTBw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Wed, Jun 15, 2016 at 7:19 PM, Martín Marqués <martin(at)2ndquadrant(dot)com> wrote:
> Hi Michael,
>
> 2016-06-15 5:00 GMT-03:00 Michael Paquier <michael(dot)paquier(at)gmail(dot)com>:
>> Martin wrote:
>>> I wonder if this is the desirable way of handling pgq, or if those
>>> tables should be dumped. I'm starting to think that this is a PgQ bug,
>>> or maybe it's not a good idea to install PgQ as an extension.
>>
>> As I am looking at that I would qualify that as a bug in pg_dump.
>> Schemas can be part of the extension definition and be linked to it,
>> and tables created on top of the schema defined in the extension
>> should really be dumped..
>
> How would the recovery process work? We expect the schema to be there
> when restoring the tables?

pg_dump creates the schema first via the CREATE EXTENSION command,
then tables dependent on this schema that are not created by the
extension are dumped individually.
--
Michael

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Yogesh Sharma 2016-06-16 03:42:53 Re: Changelog version from 8.1.2 to 9.3.6
Previous Message Jeff Janes 2016-06-15 22:50:45 Re: Question about RUM-index

Browse pgsql-hackers by date

  From Date Subject
Next Message Vitaly Burovoy 2016-06-16 03:10:54 Re: Prevent ALTER TABLE DROP NOT NULL on child tables if parent column has it
Previous Message Robert Haas 2016-06-16 03:06:37 forcing a rebuild of the visibility map