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