Re: [HACKERS] pg_dump schema breakup

2006-08-19 Thread Naz Gassiep
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Well, the other issue is how many canned breakup schemes we are going to support. If this particular one is of sufficiently general usefulness then I have no objection. But when you can produce it trivially from the

[HACKERS] pg_dump schema breakup

2006-08-18 Thread Naz Gassiep
This is my first post to a PostgreSQL mailing list, so please forgive me if I have posted to the wrong place Currently pg_dump has flags for dumping only table definitions and/or data. These flags are respectively: --schema-only --data-only I propose that two more be added: --tables-only

Re: [HACKERS] pg_dump schema breakup

2006-08-18 Thread Tom Lane
Naz Gassiep [EMAIL PROTECTED] writes: I propose that two more be added: --tables-only --constraints-only This doesn't seem well-defined at all. There are many objects in a database that are definitely neither tables nor constraints, and it's not very clear what things should be considered

Re: [HACKERS] pg_dump schema breakup

2006-08-18 Thread Naz Gassiep
Tom Lane wrote: Naz Gassiep [EMAIL PROTECTED] writes: I propose that two more be added: --tables-only --constraints-only This doesn't seem well-defined at all. There are many objects in a database that are definitely neither tables nor constraints, and it's not very

Re: [HACKERS] pg_dump schema breakup

2006-08-18 Thread Andreas Joseph Krogh
On Friday 18 August 2006 18:52, Tom Lane wrote: Naz Gassiep [EMAIL PROTECTED] writes: I propose that two more be added: --tables-only --constraints-only This doesn't seem well-defined at all. There are many objects in a database that are definitely neither tables nor constraints, and

Re: [HACKERS] pg_dump schema breakup

2006-08-18 Thread Naz Gassiep
Andreas Joseph Krogh wrote: On Friday 18 August 2006 18:52, Tom Lane wrote: Naz Gassiep [EMAIL PROTECTED] writes: I propose that two more be added: --tables-only --constraints-only This doesn't seem well-defined at all. There are many objects in a

Re: [HACKERS] pg_dump schema breakup

2006-08-18 Thread Joshua D. Drake
I think what you may really be after is the stuff that should be loaded before inserting data and the stuff that should be loaded after, but the above are poor names for these concepts. But it certainly would be nice to be able to dump all that stuff:-) Yea, I've been told that this

Re: [HACKERS] pg_dump schema breakup

2006-08-18 Thread Andrew Dunstan
Joshua D. Drake wrote: I think what you may really be after is the stuff that should be loaded before inserting data and the stuff that should be loaded after, but the above are poor names for these concepts. But it certainly would be nice to be able to dump all that stuff:-) Yea,

Re: [HACKERS] pg_dump schema breakup

2006-08-18 Thread Naz Gassiep
Andrew Dunstan wrote: We already have a highly selective and configurable restore mechanism, using the -L feature of pg_restore. Maybe there's a good special case for this particular split, but it is hardly undoable now. As for Naz' needs - I gave him a perl script I whipped up in few

Re: [HACKERS] pg_dump schema breakup

2006-08-18 Thread Alvaro Herrera
Andrew Dunstan wrote: Joshua D. Drake wrote: I think what you may really be after is the stuff that should be loaded before inserting data and the stuff that should be loaded after, but the above are poor names for these concepts. But it certainly would be nice to be able to

Re: [HACKERS] pg_dump schema breakup

2006-08-18 Thread Andrew Dunstan
Alvaro Herrera wrote: Andrew Dunstan wrote: Joshua D. Drake wrote: I think what you may really be after is the stuff that should be loaded before inserting data and the stuff that should be loaded after, but the above are poor names for these concepts. But it

Re: [HACKERS] pg_dump schema breakup

2006-08-18 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes: Well, the other issue is how many canned breakup schemes we are going to support. If this particular one is of sufficiently general usefulness then I have no objection. But when you can produce it trivially from the output of pg_dump -s, the need to