Tom,
You are 100% right about pg_restore fixing up OID references in tables to
blobs (and presumably any other objects). I should have checked more
carefully and given the program more credit.
I will remove the -o as it is not necessary, as you say.
That resolves my script problem Thanks!.
Regarding the --list output, the line reads "75; 0 BLOBS BLOBS", and listing
any database, whether or not it contains blobs, outputs the same thing (the
=20 is an email coding for EOL). So I maintain that it may be a (benign)
bug.
Colin
----- Original Message -----
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Colin Stearman" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, November 24, 2002 12:57 PM
Subject: Re: [BUGS] pg_dump/pg_restore
"Colin Stearman" <[EMAIL PROTECTED]> writes:
> 1. Large objects dumped, deleted then restored do not retain their
original=
> OIDs. Big problem as we reference their OIDs in tables.
They're not supposed to (indeed cannot). pg_restore is supposed to arrange
for references to large-object OIDs to be updated to the new values,
however. I believe it looks in columns of types OID and LO --- if you
stored your references in plain int columns, that was a mistake.
If you're using the -o option simply because you think you need it for
blobs, you don't need it.
> 2. The pg_restore command --list indicated no Blobs in the dump file even
w=
> hen there are. For example:
> 75; 0 BLOBS BLOBS=20
Looks like you have blobs to me: that entry wouldn't even be there,
otherwise.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
