Re: Re: HOLD THE PRESSES!! ... pg_dump from v7.0.3 can't import to v7.1?
| От | Peter Eisentraut |
|---|---|
| Тема | Re: Re: HOLD THE PRESSES!! ... pg_dump from v7.0.3 can't import to v7.1? |
| Дата | |
| Msg-id | Pine.LNX.4.30.0104111710460.1201-100000@peter.localdomain обсуждение исходный текст |
| Ответ на | Re: Re: HOLD THE PRESSES!! ... pg_dump from v7.0.3 can't import to v7.1? (Philip Warner <pjw@rhyme.com.au>) |
| Ответы |
Re: Re: HOLD THE PRESSES!! ... pg_dump from v7.0.3
can't import to v7.1?
|
| Список | 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 по дате отправления: