Re: AW: Re: pg_dump and LOs (another proposal)
От | Philip Warner |
---|---|
Тема | Re: AW: Re: pg_dump and LOs (another proposal) |
Дата | |
Msg-id | 3.0.5.32.20000706182021.024e2c20@mail.rhyme.com.au обсуждение исходный текст |
Ответ на | AW: Re: pg_dump and LOs (another proposal) (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>) |
Список | pgsql-hackers |
At 09:52 6/07/00 +0200, Zeugswetter Andreas SB wrote: >> >> I'll also have to modify pg_restore to talk to the database >> directly (for >> lo import). As a result I will probably send the entire >> script directly >> from withing pg_restore. Do you know if comment parsing >> ('--') is done in >> the backend, or psql? > >Strictly speaking you are absolutely safe if you only do one update >with the max oid from the 30,000 rows before you start creating the lo's. >Don't know if you know that beforehand though. > >If you only know afterwards then you have to guarantee that no other >connection to this db (actually postmaster if you need the oid's site >unique) >does anything while you insert the lo's and then update to max oid. > You may be confusing the two proposed techniques, the current flavour of the minute is to restore the BLOBs using lo_craete to get a new oid; write an entry in a table indicating what the old & new are, then when the table data is loaded, update all oid fields that refer to oids in the xref table. It's pretty nasty, but it has the big advantage of being as vanilla as possible. It's also pretty close to what pg_dump_lo does. ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.C.N. 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
В списке pgsql-hackers по дате отправления: