Thread: pg_dump compatibility with 7.0
I've been messing around with a 7.0 compatible dump for 7.1, and it looks good so far (at least I can dump & restore my local DBs and, to some extent, the regression DB, including BLOBs). It is a mixture of 7.1 and 7.0 features, in the sense that it is basically the 7.1 pg_dump but with 7.0 SQL/methods where necessary. As a result it dumps in OID order etc but has the 7.0 type formatting for 7.0 databases. It also uses pg_views to get the view definition, and, at least on 7.0.2, the view was mildly broken so the regression DB does not dump properly. I'd be interested in feedback etc, if people don't mind. The patch (against CVS) can be found at: ftp://ftp.rhyme.com.au/pub/postgresql/pg_dump/pg_dump_1504_patch.gz At the moment it has no idea what do do with aggregates (is there anything?), and it assumes 'proisstrict' on functions. ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 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 |/
Philip Warner <pjw@rhyme.com.au> writes:
> At the moment it has no idea what do do with aggregates (is there
> anything?), and it assumes 'proisstrict' on functions.
I'll take the blame for the aggregate issue ;-).
SFUNC1/STYPE1/INITCOND1 in 7.0 equate to SFUNC/STYPE/INITCOND in 7.1.
There is no 7.1 equivalent to 7.0's SFUNC2/STYPE2/INITCOND2 --- those
have to be saved/restored separately if you are dumping a 7.0 database
with intentions of restoring it to 7.0. On the other hand, if you are
dumping 7.0 with an eye to restoring to 7.1, you could just as well
raise an error if those fields are nonnull.
Assuming 'proisstrict' for a 7.0 function seems reasonable.
regards, tom lane
At 01:08 15/04/01 -0400, Tom Lane wrote: > >SFUNC1/STYPE1/INITCOND1 in 7.0 equate to SFUNC/STYPE/INITCOND in 7.1. >There is no 7.1 equivalent to 7.0's SFUNC2/STYPE2/INITCOND2 It now outputs a warning to stderr as well as the dump file. > --- those >have to be saved/restored separately if you are dumping a 7.0 database >with intentions of restoring it to 7.0. I'm not sure I want to support 7.0->7.0 (or 7.1->7.0) in the dump for 7.1. This could get really messy in a few versions time. It's mainly to allow smoother upward conversions. >On the other hand, if you are >dumping 7.0 with an eye to restoring to 7.1, you could just as well >raise an error if those fields are nonnull. Done. It does not crash the dump, but it does write a 'warning entry' to stderr & the dump file so that subsequent a pg_restore will display a warning as well. Amended file available at: ftp://ftp.rhyme.com.au/pub/postgresql/pg_dump/pg_dump_1505_patch.gz At the moment the version compatibility changes are relatively trivial, so I'm not sure there is any value in creating multiple modules (I had thought one per version would be TWTG). Should I apply this to CVS when it's been a little more tested? ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 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 |/