Re: Suggested "easy" TODO: pg_dump --from-list

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Suggested "easy" TODO: pg_dump --from-list
Date: 2010-11-24 12:29:56
Message-ID: AANLkTim_RDgp9JOOUxaB4zfRi+xnaKwBOx79JV1prBa_@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-11-24 12:37:00 Re: final patch - plpgsql: for-in-array
Previous Message Robert Haas 2010-11-24 12:02:53 Re: profiling connection overhead