Re: Re: pg_dump and LOs (another proposal) - Mailing list pgsql-hackers

From Philip Warner
Subject Re: Re: pg_dump and LOs (another proposal)
Date
Msg-id 3.0.5.32.20000707022200.026c5240@mail.rhyme.com.au
Whole thread Raw
In response to Re: Re: pg_dump and LOs (another proposal)  (Philip Warner <pjw@rhyme.com.au>)
Responses Re: Re: pg_dump and LOs (another proposal)  (Karel Zak <zakkr@zf.jcu.cz>)
Re: Re: pg_dump and LOs (another proposal)  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
At 18:12 6/07/00 +0200, Peter Eisentraut wrote:
>Philip Warner writes:
>
>> I'll also have to modify pg_restore to talk to the database directly (for
>> lo import).
>
>psql has \lo_import.
>

This is true, but if there are 30000 blobs on an archive tape, I cant dump
them into /tmp and wait for the user to run the script. At the current time
pg_restore just sends a script to a file or stdout - it has no guarantee of
when a \lo_import command will be run, so dumping blobs into the same file
between lo_import calls would not be appropriate, since I am in effect
requiring a psql attachment. 

So the plan is, in the first pass, to make BLOB restoration dependant on
having a DB connection.

Does this make more sense?

P.S. I have only half-written the lo dumping code, so this is all quite
open...




----------------------------------------------------------------
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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: build system
Next
From: Philip Warner
Date:
Subject: Re: zlib for pg_dump