Re: [GENERAL] pg_dump -s dumps data?! - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [GENERAL] pg_dump -s dumps data?!
Date
Msg-id 7228.1328644567@sss.pgh.pa.us
Whole thread Raw
In response to Re: [GENERAL] pg_dump -s dumps data?!  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: [GENERAL] pg_dump -s dumps data?!  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.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


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: When do we lose column names?
Next
From: Tom Lane
Date:
Subject: Re: When do we lose column names?