On Wed, Nov 24, 2010 at 1:15 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Josh Berkus <josh@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