On Monday, January 30, 2012 8:25:54 am hubert depesz lubaczewski wrote:
> On Mon, Jan 30, 2012 at 08:20:15AM -0800, Adrian Klaver wrote:
> > I am not sure I understand crippled. There is a bug that you acknowledge
> > has been dealt with. The rest is documented behavior having to do with
> > extension packaging. Extensions exist as packages and are put into the
> > database and pulled from the database as such, by the extension
> > mechanism. Whether data is included in that process is up to the
> > discretion of the extension creator. So on that particular point you
> > probably need to talk to the folks that created the extension. The
> > learning curve exists because now a db admin has to understand that the
> > extension mechanism exists and the ways it interacts with the rest of
> > the database.
>
> crippled in this way:
> it is not possible to have table from extension that will have its data
> dumped in normal pg_dump (or pg_dump -a), and will *not* have its data
> dumped when doing pg_dump -s or pg_dump -s -t other_table.
Well the only part I see as broken is if you do pg_dump -s -t some_table and
that causes data to be dumped from extension table(s) with out asking. This in
the case where some_table has nothing to do with the extension. If you do
pg_dump -s for an entire database I would expect the data to be dumped if it was
configured by pg_catalog.pg_extension_config_dump(). When that function is run
by the extension creator, they are essentially saying that data is needed to set
up the extension and therefore it is schema. Otherwise you would not be able to
replicate an extensions state in the dump/restore cycle in those cases where
that is important. At least that is how I see it.
>
> you either have data for extension-based-tables in *all* dumps
> or
> you don't have data for extension-based-tables in *any* dumps.
>
> Best regards,
>
> depesz
--
Adrian Klaver
adrian.klaver@gmail.com
