Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] pg_dump -s dumps data?!

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: depesz(at)depesz(dot)com, Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, pgsql-general(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] pg_dump -s dumps data?!
Date: 2012-01-31 12:36:46
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackers
On Mon, Jan 30, 2012 at 11:18 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I don't recall that we thought very hard about what should happen when
> pg_dump switches are used to produce a selective dump, but ISTM
> reasonable that if it's "user data" then it should be dumped only if
> data in a regular user table would be.


> What's not apparent to me is whether there's an argument for doing more
> than that.  It strikes me that the current design is not very friendly
> towards the idea of an extension that creates a table that's meant
> solely to hold user data --- you'd have to mark it as "config" which
> seems a bit unfortunate terminology for that case.  Is it important to
> do something about that, and if so what?

Is this anything more than a naming problem?

Robert Haas
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2012-01-31 13:06:51
Subject: Re: [v9.2] Add GUC sepgsql.client_label
Previous:From: hubert depesz lubaczewskiDate: 2012-01-31 10:30:14
Subject: Re: [GENERAL] pg_dump -s dumps data?!

pgsql-general by date

Next:From: Marti RaudseppDate: 2012-01-31 13:14:54
Subject: Re: Why Hard-Coded Version 9.1 In Names?
Previous:From: durumdaraDate: 2012-01-31 12:16:45
Subject: Extending Session / Logged User info

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group