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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: depesz(at)depesz(dot)com, Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com>, Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [GENERAL] pg_dump -s dumps data?!
Date: 2012-02-08 20:31:18
Message-ID: 136.1328733078@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Vincent Veyron 2012-02-08 22:40:05 Re: Don't Thread On Me (PostgreSQL related)
Previous Message Andreas Kretschmer 2012-02-08 17:13:36 Re: easy function or trigger to UPPER() all alpha data

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-02-08 20:36:45 Re: Bugs/slowness inserting and indexing cubes
Previous Message Alexander Korotkov 2012-02-08 20:10:38 Re: Bugs/slowness inserting and indexing cubes