Horton

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

Adrian Klaver <adrian.klaver@gmail.com>

View thread
From: Adrian Klaver <adrian.klaver@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, depesz@depesz.com, Dimitri Fontaine <dimitri@2ndquadrant.fr>, pgsql-general@postgresql.org, pgsql-hackers@postgresql.org
Date: 2012-01-31T22:37:45Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add --section option to pg_dump and pg_restore.

  2. Add --exclude-table-data option to pg_dump.

On 01/31/2012 04:36 AM, Robert Haas wrote:
> On Mon, Jan 30, 2012 at 11:18 PM, Tom Lane<tgl@sss.pgh.pa.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.
>
> Yep.
>
>> 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?

Seems to me that would be dependent on what the future plans are for the 
extension mechanism. There is also the issue of backward compatibility 
for those people that are using configuration tables in their extensions 
and would like to maintain that separation. I could see adding another 
function that is similar and would be used to identify strictly user 
data tables.



-- 
Adrian Klaver
adrian.klaver@gmail.com