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 по дате отправления: