Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Adrian Klaver <adrian.klaver@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, depesz@depesz.com, Dimitri Fontaine <dimitri@2ndquadrant.fr>, pgsql-general@postgresql.org, pgsql-hackers@postgresql.org
Date: 2012-01-31T23:07:51Z
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.

Adrian Klaver <adrian.klaver@gmail.com> writes:
> 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:
>>> 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.

My thought exactly --- maybe it's only a minor cosmetic issue that will
affect few people, or maybe this will someday be a major use-case.
I don't know.  I was hoping Dimitri had an opinion.

			regards, tom lane