Horton

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

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

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: depesz@depesz.com, Adrian Klaver <adrian.klaver@gmail.com>, Dimitri Fontaine <dimitri@2ndQuadrant.fr>, pgsql-hackers@postgresql.org
Date: 2012-02-08T20:31:18Z
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.

Andrew Dunstan <andrew@dunslane.net> writes:
> OK, in this version we simply suppress creation of the TableDataInfo 
> object if it's not wanted.

I applied this with some further adjustments.

> I actually removed the code from 
> makeTableDataInfo - there are only two places it gets called and doing 
> it in those two spots seemed a bit cleaner.

After study it seemed to me that this was the wrong direction to take.
It was already the case that the config-table path was skipping the
filters in getTableData(), none of which seem to be good for it to skip
other than the one on the table's schema-dump flag.  So I've refactored
the code to put all those filters into makeTableDataInfo where they
will be applied to both the normal and config-table cases.

Now, back to the original subject of this thread: both HEAD and 9.1 are
now operating as designed, in that they will dump the (user-provided
portion of the) contents of an extension config table whenever that
extension is dumped, even if --schema is specified.  Do we want to
change that?  I'm not convinced that it's something to mess with
lightly.  I could possibly support a definition that says that we omit
such data in --schema mode, except that I'm not sure what is sensible
for rows that were modified (not inserted) by user actions.  Also, we
probably ought to get some input from the postgis people, because after
all this entire feature was designed for their schema auxiliary tables.

			regards, tom lane