Re: pg_dump -s dumps data?! - Mailing list pgsql-general

From Adrian Klaver
Subject Re: pg_dump -s dumps data?!
Date
Msg-id 201201300820.15879.adrian.klaver@gmail.com
Whole thread Raw
In response to Re: pg_dump -s dumps data?!  (hubert depesz lubaczewski <depesz@depesz.com>)
Responses Re: pg_dump -s dumps data?!  (hubert depesz lubaczewski <depesz@depesz.com>)
List pgsql-general
On Monday, January 30, 2012 7:39:13 am hubert depesz lubaczewski wrote:
> On Mon, Jan 30, 2012 at 07:34:49AM -0800, Adrian Klaver wrote:
> > Breaks certain cases when using pg_dump -s.  Some of what you highlight
> > above is designed behavior. What is happening is covered by my second
> > rule of life 'Easy is difficult'. In this case it is the desire for a
> > built in 'packaging' system that makes extending Postgres easier for the
> > end user.  To get that leads to more complexity in the backend and a new
> > learning curve for those that have to deal with it.
>
> not sure what "learning curve" you have in mind, since it simply
> cripples functionality of pg_dump.
> how steep is the learning curve, to learn that you no longer can make
> sensible "pg_dump -s"?

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.

>
> Best regards,
>
> depesz

--
Adrian Klaver
adrian.klaver@gmail.com

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_dump -s dumps data?!
Next
From: Tom Lane
Date:
Subject: Re: Extensions btree_gist and cube collide?