Re: Patch for pg_dump - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Patch for pg_dump
Date
Msg-id 4601BDF3.50401@dunslane.net
Whole thread Raw
In response to Re: Patch for pg_dump  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
>   
>> I guess this matches this TODO item:
>>         o Allow selection of individual object(s) of all types, not just
>>           tables
>>     
>
> Well, it's a subset of it, but do we want to accept a patch that's been
> designed with only a subset in mind?  I'd like to see a roadmap for what
> a complete facility for this would look like, to make sure we aren't
> going down a dead end.
>
> One thing that looks particularly dead-end-ish here is the switch name.
> We might be well advised to have only long-form switches for these
> things, 'cause we'll surely run out of suitable single letters (in fact,
> if "Q" is as close as one can get to "function", we already have).
>
> Another question that seems particularly relevant is how the patch scales
> up to specifying (a) function's schema name, (b) argument types (in case
> the function name is overloaded).
>
> Code-wise, the patch seems a bit of a mess too --- it will certainly not
> scale up to dumping some functions and some other things, as one would
> expect for instance if one said "pg_dump -Q myfunc -t mytab ...".  It
> doesn't even look like it will handle multiple -Q switches.  I think a
> minimum expectation is that -Q would work like -t now does.
>
>
>   

Along similar lines, what happened to the idea of pre-data and post-data 
dump subsets that was discussed not so long ago, unless my memory is 
playing tricks again?

cheers

andrew


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: fixing dllist?
Next
From: Grzegorz Jaskiewicz
Date:
Subject: Re: relation 71478240 deleted while still in use on 8.1