On Wed, Nov 24, 2010 at 1:15 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Josh Berkus <j...@agliodbs.com> writes: >>> Well, very little about pg_dump is very [E], IMNSHO. The question in my >>> mind here is what format the list file will take > >> I was thinking same format as pg_restore -l, only without the dumpIDs. > > Nope ... those strings are just helpful comments, they aren't really > guaranteed to be unique identifiers. In any case, it seems unlikely > that a user could expect to get the more complicated cases exactly right > other than by consulting "pg_dump | pg_restore -l" output. Which makes > the use-case kind of dubious to me. > > I don't say that this wouldn't be a useful feature, but you need a > better spec than this.
One thing I've often wished for is the ability to dump a specific function (usually right after after I accidentally rm the file the source code was in). pg_dump has -t to pick a table, but there's no analagous way to select an object that isn't a relation. I think the first step here would be to design a system that lets you use a command-line argument to dump an arbitrary object, and after that you could work on reading the object descriptors from a file rather than the command line. As a first attempt at syntax, I might suggest something along the lines of "object type: object name", where the types and names might look to COMMENT ON for inspiration. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
