
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   |/

Sun, 15 Apr 2001 13:35:42 +1000
Philip Warner <pjw@rhyme.com.au>
pg_dump compatibility with 7.0
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

Sun, 15 Apr 2001 01:08:46 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_dump compatibility with 7.0 
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   |/

Mon, 16 Apr 2001 02:09:48 +1000
Philip Warner <pjw@rhyme.com.au>
Re: pg_dump compatibility with 7.0 