Re: pg_restore --no-post-data and --post-data-only

On 08/26/2011 12:46 PM, Robert Haas wrote:
> On Fri, Aug 26, 2011 at 11:22 AM, Andrew Dunstan<andrew@dunslane.net>  wrote:
>>> But we could also add these switches to pg_dump too if people feel it's
>>> worthwhile. I haven't looked but the logic should not be terribly hard.
>> Something like the attached, in fact, which seems pretty simple.
> It seems like there are three sets of things you might want here:
> pre-data, data, post-data.  So in the end we could end up with:
>
> --pre-data-only
> --post-data-only
> --data-only
> --no-pre-data
> --no-post-data
> --no-data
>
> And then maybe someone will want just the create index commands and
> not the constraint commands.  It seems like it might be more elegant
> to come up with a single switch where you can list which things you
> want:
>
> --sections='predata data'
> --sections='postdata'
> --sections='index'
>
> Just thinking out loud....

I knew there would be some bike-shedding about how we specify these 
things, which is why I haven't written docs yet.

All the possibilities you specify except for the indexes section can be 
done by using these switches in combination with -s and -a.

For anything more fine-grained, I'm inclined to say that people need to 
roll their own. pg_restore's --list and --use-list give you extremely 
fine-grained control. I have working scripts which use these for example 
to filter out londiste and pgq objects, certain large tables, audit 
objects and more. As an example of the complexity I think we should 
avoid, which section would UNIQUE and PRIMARY KEY constraints belong in? 
"constraints" because that's what they are, or "indexes" because that's 
what they create? No matter which answer you choose someone will claim 
you have violated POLA.

Chopping things into pre-data, data and post-data would get us around 
99% of the cases we could reasonably provide for in my experience. That 
seems enough :-)

I don't have anything in principle against your '--sections="foo bar"' 
suggestion, but it would be more work to program. Simpler, and probably 
more consistent with how we do other things, would be allowing multiple 
--section options, if we don't want to have named options such as I have 
provided.

cheers

andrew