Re: Re: HOLD THE PRESSES!! ... pg_dump from v7.0.3 can't import to v7.1? - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Re: HOLD THE PRESSES!! ... pg_dump from v7.0.3 can't import to v7.1?
Date
Msg-id Pine.LNX.4.30.0104111710460.1201-100000@peter.localdomain
Whole thread Raw
In response to Re: Re: HOLD THE PRESSES!! ... pg_dump from v7.0.3 can't import to v7.1?  (Philip Warner <pjw@rhyme.com.au>)
Responses Re: Re: HOLD THE PRESSES!! ... pg_dump from v7.0.3 can't import to v7.1?
List pgsql-hackers
Philip Warner writes:

> At 01:09 11/04/01 +0200, Peter Eisentraut wrote:
> >
> >Btw., it would really seem like a neat feature if a given pg_dump suite
> >would also handle the respective previous version.
>
> This has been in the back of my mind for some time, and is why I initially
> backported my pg_dump changes to 7.0. Unfortunately, I did not continue,
> and the backport wa targetted at 7.0, not 7.1.

This is not really what I had in mind.  Backporting enhancements would
only serve the users that manually installed the enhancements.  Actually,
it's quite idiosyncratic, because the point of a new release is to publish
enhancements.

What I meant was that whenever the backend changes in a way that mandates
pg_dump changes we would leave the old way in place and only add a new
case to handle the new backend.  Stupid example:

switch (backend_version)
{case 71:    result = PQexex("select * from pg_class;");    break;case 72:    result = PQexec("select * from
pg_newnameforpgclass;");   break;
 
}

This would invariably introduce code bloat, but that could probably be
managed by a modular design within pg_dump, plus perhaps removing support
for really old versions once in a while.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/



pgsql-hackers by date:

Previous
From: Thomas Lockhart
Date:
Subject: Re: Indexes not used in 7.1RC4: Bug?
Next
From: Philip Warner
Date:
Subject: Re: Re: HOLD THE PRESSES!! ... pg_dump from v7.0.3 can't import to v7.1?