Mention pg_dump version portability

Started by Bruce Momjianalmost 20 years ago8 messageshackersdocs
Jump to latest
#1Bruce Momjian
bruce@momjian.us
hackersdocs

I have applied this patch that mentions pg_dump portability to 8.1.X and
CVS HEAD.

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Attachments:

/rtmp/difftext/x-diffDownload+11-0
#2Jim Nasby
Jim.Nasby@BlueTreble.com
In reply to: Bruce Momjian (#1)
hackersdocs
Re: Mention pg_dump version portability

On Sat, May 13, 2006 at 12:21:06PM -0400, Bruce Momjian wrote:

I have applied this patch that mentions pg_dump portability to 8.1.X and
CVS HEAD.

Would it be worth recommending using the custom format over plain? I see
plenty of issues with incompatabilities in the plain version, but I
don't think I've ever seen problem with the custom format (though this
could just be because everyone uses the default...)
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

#3Bruce Momjian
bruce@momjian.us
In reply to: Jim Nasby (#2)
hackersdocs
Re: Mention pg_dump version portability

Jim C. Nasby wrote:

On Sat, May 13, 2006 at 12:21:06PM -0400, Bruce Momjian wrote:

I have applied this patch that mentions pg_dump portability to 8.1.X and
CVS HEAD.

Would it be worth recommending using the custom format over plain? I see
plenty of issues with incompatabilities in the plain version, but I
don't think I've ever seen problem with the custom format (though this
could just be because everyone uses the default...)

Right, it is just because it is the default.

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

#4Jim Nasby
Jim.Nasby@BlueTreble.com
In reply to: Bruce Momjian (#3)
hackersdocs
Re: Mention pg_dump version portability

On Mon, May 15, 2006 at 07:43:20PM -0400, Bruce Momjian wrote:

Jim C. Nasby wrote:

On Sat, May 13, 2006 at 12:21:06PM -0400, Bruce Momjian wrote:

I have applied this patch that mentions pg_dump portability to 8.1.X and
CVS HEAD.

Would it be worth recommending using the custom format over plain? I see
plenty of issues with incompatabilities in the plain version, but I
don't think I've ever seen problem with the custom format (though this
could just be because everyone uses the default...)

Right, it is just because it is the default.

But shouldn't the custom format deal better with version changes, or
does the format of custom change just as often? Though, even if it did
change just as often, pg_restore should be able to deal better with it
than psql, since pg_restore knows it's a dump and knows what version
it's coming from...
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

#5Tom Lane
tgl@sss.pgh.pa.us
In reply to: Jim Nasby (#4)
hackersdocs
Re: Mention pg_dump version portability

"Jim C. Nasby" <jnasby@pervasive.com> writes:

But shouldn't the custom format deal better with version changes, or
does the format of custom change just as often?

It's completely orthogonal, because the SQL involved is just the same.
One of the tests I periodically run is to compare
pg_dump >foo
pg_dump -Fc | pg_restore >bar
and make sure the outputs are word-for-word the same.

What custom or tar format buys you is the flexibility of extracting
different subsets of the dump after-the-fact, using pg_restore's
switches. Of course you can do that with a text editor on a plain
dump, if the dump's not too large for your editor to handle ...

regards, tom lane

#6Jim Nasby
Jim.Nasby@BlueTreble.com
In reply to: Bruce Momjian (#3)
hackersdocs
Re: Mention pg_dump version portability

Grr, deleted Tom's email before I replied...

pg_dump -Fc | pg_restore will only match the output of pg_dump if
everything's the same version though, right? Or wrong? What happens if
pg_dump -Fc is and older version and pg_restore is the current version?

Or is the custom format the same as the text/SQL dump, just with some
fancy wrappers around it?
--
Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

#7Tom Lane
tgl@sss.pgh.pa.us
In reply to: Jim Nasby (#6)
hackersdocs
Re: Mention pg_dump version portability

"Jim C. Nasby" <decibel@decibel.org> writes:

pg_dump -Fc | pg_restore will only match the output of pg_dump if
everything's the same version though, right? Or wrong? What happens if
pg_dump -Fc is and older version and pg_restore is the current version?

There would probably be some small differences, but 99% of pg_restore's
output is just regurgitating SQL it finds in the dump file.

regards, tom lane

#8Jim Nasby
Jim.Nasby@BlueTreble.com
In reply to: Tom Lane (#7)
hackersdocs
Cross-version dumps (was: [DOCS] Mention pg_dump version portability)

Moving to -hackers.

On Wed, May 17, 2006 at 12:13:49PM -0400, Tom Lane wrote:

"Jim C. Nasby" <decibel@decibel.org> writes:

pg_dump -Fc | pg_restore will only match the output of pg_dump if
everything's the same version though, right? Or wrong? What happens if
pg_dump -Fc is and older version and pg_restore is the current version?

There would probably be some small differences, but 99% of pg_restore's
output is just regurgitating SQL it finds in the dump file.

Maybe it's time to look at improving pg_restore's ability to deal with
cross-version issues, and make it the default for pg_dump. ISTM there's
been a fair amount of contortions as of late around pg_dump SQL
compatability. If the custom format at least included pg_dump version
information, and pg_restore new what version of PostgreSQL it was
restoring into, it could handle these cases more elegantly than is
possible with just dumping straight into psql. Or it might make more
sense for the custom format to be something that's less sensitive to
some of these compatability issues.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461