From: | Joachim Wieland <joe(at)mcknight(dot)de> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Suggested "easy" TODO: pg_dump --from-list |
Date: | 2010-11-24 04:08:00 |
Message-ID: | AANLkTinfPw1SQAYsiztj8XCx2BibF9w6U+8U-EgDC+_T@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Nov 23, 2010 at 10:24 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> Well, very little about pg_dump is very [E], IMNSHO. The question in my mind
> here is what format the list file will take. For example, how would we
> specify a function? Would we need to specify all the argument types (or at
> least the IN arguments)? It's not as easy as a list with pg_restore, which
> is just a list of TOC ids, and all the rest is just a comment in the list
> file.
>
> I certainly don't think we should put this on the list without at least
> having the idea fleshed out some more.
I think the list should be generated by pg_dump itself in a first run,
by building a complete TOC and then dumping a "pg_restore -l" like
list format (without dumpIds) where the user just deletes the objects
that he doesn't want to get dumped. The list wouldn't contain dumpIds,
but catalogIds and those should be sufficiently unique and easy to
parse and compare.
Joachim
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2010-11-24 04:27:33 | Assertion failure on hot standby |
Previous Message | Andrew Dunstan | 2010-11-24 03:24:09 | Re: Suggested "easy" TODO: pg_dump --from-list |