Re: pg_restore --no-post-data and --post-data-only
От | Jim Nasby |
---|---|
Тема | Re: pg_restore --no-post-data and --post-data-only |
Дата | |
Msg-id | F6248CFD-44FA-4B03-926C-E8FDBEDAF79A@nasby.net обсуждение исходный текст |
Ответ на | Re: pg_restore --no-post-data and --post-data-only (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: pg_restore --no-post-data and --post-data-only
|
Список | pgsql-hackers |
On Aug 24, 2011, at 7:43 PM, Josh Berkus wrote: > On 8/23/11 1:30 PM, Andrew Dunstan wrote: >> >> Attached is an undocumented patch that allows pg_restore to omit >> post-data items or omit all but post-data items. This has been discussed >> before, and Simon sent in a patch back on 2008, which has bitrotted >> some. I'm not sure why it was dropped at the time, but I think it's time >> to do this. This patch relies on some infrastructure that was added >> since Simon's patch, so it works a bit differently (and more simply). > > If it's not clear from Andrew's description, the purpose of this patch > is to allow dividing your pgdump into 3 portions: > > 1. schema > 2. data > 3. constraints/indexes > > This allows users to implement a number of custom solutions for ad-hoc > parallel dump, conditional loading, data munging and sampled databases. > While doing so was possible before using the manifest from pg_restore > -l, the manifest approach has been complex to automate and relies on > obscure knowledge. > > I have immediate production use for this patch and may be backporting it. FWIW, I got around this by writing a perl script that calls pg_dump -s and watches for the end of table create statements(IIRC it specifically looks for the first CREATE INDEX). The advantage to that approach is that you don't haveto first create a custom format dump and then run pg_restore against that. -- Jim C. Nasby, Database Architect jim@nasby.net 512.569.9461 (cell) http://jim.nasby.net
В списке pgsql-hackers по дате отправления: