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