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-07 19:56:07
Message-ID: 7228.1328644567@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:
> On 01/31/2012 11:10 PM, Andrew Dunstan wrote:
>> Here's a possible patch for the exclude-table-data problem along the
>> lines you suggest.

> Should I apply this?

I'm not happy with this yet. My core complaint is that pg_dump used to
consider that creation of a TableDataInfo object for a table happens
if and only if we're going to dump the table's data. And the comments
(eg in pg_dump.h) still say that. But the previous patch left us in a
halfway zone where sometimes we'd create a TableDataInfo object and then
choose not to dump the data, and this patch doesn't get us out of that.
I think we should either revert to the previous definition, or go over
to a design wherein we always create TableDataInfo objects for all
tables (but probably still excluding data-less relations such as views)
and the whether-to-dump decision is expressed only by setting or not
setting the object's dump flag.

I worked a little bit on a patch to do the latter but found that it was
more invasive than I'd hoped. Given the lack of any immediate payoff
I think it'd probably make more sense to do the former. We could still
centralize the decision making into makeTableDataInfo a bit more than
now, but it should take the form of not creating the object at all,
rather than creating it and then clearing its dump flag.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Marti Raudsepp 2012-02-07 20:47:06 Re: SOUNDEX call
Previous Message Andreas Kretschmer 2012-02-07 17:21:30 Re: Postgres Table level statement logging

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-02-07 20:03:03 Re: When do we lose column names?
Previous Message Andrew Dunstan 2012-02-07 19:45:10 Re: When do we lose column names?