Re: (A) native Windows port

> > Keys to this working:
> > 1.) Must not require the old version executable backend. There are a
number
> > of reasons why this might be, but the biggest is due to the way much
> > upgrading works in practice -- the old executables are typically gone by
the
> > time the new package is installed.
>
> Oh, that is a problem. We would have to require the old executables.

Could this be solved with packaging? Meaning can postmasters from old versions
be packed with a new release strictly for the purpose of upgrading? It is my
understanding that the only old executable needed is the postmaster is that
correct? Perhaps this also requires adding functionality so that pg_dump can
run against a singer user postmaster.

Example: When PG 7.3 is released, the RPM / deb / setup.exe include the
postmaster binary for v 7.2 (perhaps two or three older versions...). An
upgrade script is included that does the automatic dump / restore described
eariler in this thread. Effectivly, you are using old versions of the
postmaster as your standalone dumper.

I think this could sidestep the problem of having to create / test / maintain
new version of a dumper or pg_upgrade for every release.

By default perhaps the postmaster for the previous version of postgres is
included, and postmasters from older versions are distrubuted in separate
packages, so if I am still runnig 6.5.3 and I want to upgrade to 7.3, I have
do install the 6.5.3 upgrade package. Or perhaps there i one pg_upgrade rpm
package that includes every postmaster since 6.4. This would allow the
upgrade script to know that it all backends are availble to it depeding on
what it finds in PG_VERSION, it also allows the admin to removed them all
easily once they are no longer needed.