Re: pg_dump schema breakup - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: pg_dump schema breakup
Date
Msg-id 44E61B21.9060704@dunslane.net
Whole thread Raw
In response to Re: pg_dump schema breakup  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: pg_dump schema breakup
List pgsql-hackers
Alvaro Herrera wrote:
> Andrew Dunstan wrote:
>   
>> Joshua D. Drake wrote:
>>     
>>>>>> I think what you may really be after is "the stuff that should be 
>>>>>> loaded
>>>>>> before inserting data" and "the stuff that should be loaded after", 
>>>>>> but
>>>>>> the above are poor names for these concepts.
>>>>>>    
>>>>>>             
>>>>> But it certainly would be nice to be able to dump all that "stuff":-)
>>>>>           
>>>> Yea, I've been told that this would not be a high demand feature. So 
>>>> do I have a second vote? ;-)
>>>>         
>>> The ability to have a dump that automatically separated the 
>>> before-data and after-data objects is definitely
>>> useful. The amount of times I have had to dump the schema and data 
>>> separately just so I can modify the
>>> schema before restore, or disable some function that is causing 
>>> problems can not even be counted.
>>>
>>>       
>> We already have a highly selective and configurable restore mechanism, 
>> using the -L feature of pg_restore. Maybe there's a good special case 
>> for this particular split, but it is hardly undoable now.
>>
>> As for Naz' needs - I gave him a perl script I whipped up in few minutes 
>> to do the split he wanted - and I'm sure you could do the same in python ;-)
>>     
>
> Maybe what we need is a program to process the object list from
> pg_restore -L.  Or a mode in pg_restore, "from this dump give me all
> the sutff to be loaded before inserting data", and the reverse.
>
> I mean, should the problem be attacked while dumping, or while
> restoring?
>
>   

Well, the other issue is how many canned breakup schemes we are going to 
support. If this particular one is of sufficiently general usefulness 
then I have no objection. But when you can produce it trivially from the 
output of "pg_dump -s", the need to hardcode it hardly seems pressing.

cheers

andrew


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: libpq Describe Extension [WAS: Bytea and perl]
Next
From: Tom Lane
Date:
Subject: Re: pg_dump schema breakup