From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Oliver Elphick <olly(at)lfix(dot)co(dot)uk> |
Cc: | "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>, Jan Wieck <JanWieck(at)Yahoo(dot)com>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, HACKERS <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: (A) native Windows port |
Date: | 2002-07-09 17:05:55 |
Message-ID: | 1026234355.7894.121.camel@taru.tm.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Tue, 2002-07-09 at 17:49, Oliver Elphick wrote:
> On Tue, 2002-07-09 at 16:41, Hannu Krosing wrote:
> > On Tue, 2002-07-09 at 13:48, Oliver Elphick wrote:
> > > On Tue, 2002-07-09 at 01:30, Matthew T. O'Connor wrote:
> > > > 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...).
> > >
> > > That isn't usable for Debian. A package must be buildable from source;
> > > so I would have to include separate (though possibly cut-down) source
> > > for n previous packages. It's a horrid prospect and a dreadful kludge
> > > of a solution - a maintainer's nightmare.
> >
> > The old postmaster should not be built/distributed. As it is for
> > _upgrading_ only, you just have to _keep_ it when doing an upgrade, not
> > build a new "old" one ;)
>
> No, it doesn't work like that. You cannot rely on anything's being left
> from an old distribution; apt is quite likely to delete it altogether
> before installing the new version (to enable dependencies to be
> satisfied). At present I have the preremoval script copy the old
> binaries to a special location in case they will be needed, but that
> fails if the version is very old (and doesn't contain that code), and
> it's a very fragile mechanism.
>
> I never have understood why the basic table structure changes so much
> that it can't be read; just what is involved in getting the ability to
> read old versions?
The big change was from 6.x to 7.x where a chunk of data moved from end
of page to start of page and tableoid column was added. Otherways the
table structure is quite simple. The difficulties with user _data_ can
be mainly because of binary format changes for some types and such.
But I still can't see how will having a binary dumper that does mostly
the work of [ old_backend -c "COPY tablex TO STDOUT" ] help us here.
IIRC the main difficulties in upgrading have always been elsewhere, like
migrating always changing system table data.
----------
Hannu
From | Date | Subject | |
---|---|---|---|
Next Message | Marc G. Fournier | 2002-07-09 17:09:23 | Re: I am being interviewed by OReilly |
Previous Message | Robert L Mathews | 2002-07-09 16:50:52 | Re: Query Casting Help |
From | Date | Subject | |
---|---|---|---|
Next Message | Marc G. Fournier | 2002-07-09 17:09:23 | Re: I am being interviewed by OReilly |
Previous Message | Hannu Krosing | 2002-07-09 16:57:54 | Re: (A) native Windows port |