On Tue, Jul 03, 2007 at 07:13:29PM +0200, Zdenek Kotala wrote:
> pg_migrator is separate tool which requires old postgres version and I
> would like to have solution in postgres binary without old version
> presence. Very often new postgres version is store in same location
> (e.g. /usr/bin) and normal users could have a problem.
Possibly. But you have to demonstrate it actually works and it's best
to do that with a seperate process. Or fix pg_migrator to not require
the old version, either way will do.
> > I think insisting on a downgrade option is an absolutely certain way
> > of guaranteeing that the project will fail.
>
> How I mentioned before. This is nice to have requirement. I would like
> to have in the mind and when it starts complexity explosion we can
> remove it from the requirement list.
It seems to me that if every step of the process is WAL logged, then
downgrading is simply a matter of restoring and using PITR. Downgrades
are hard work, primarily because in the long run it's going to be
totally untested code because hardly anyone is going to need it.
> Yes, there is way to keep old and new implementation of index and each
> will have different oid. Primary key for pg_am table will be
> name+pg_version - It is similar to UDT solution. CREATE INDEX as a
> REINDEX will use actual implementation.
Bad idea. Indexes are already complicated peices of code, there's no
guarentee the old code will even work with the new version. Seems like
too much work considering REINDEX will simply fix the problem outright.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.