Tying to my last post, concerning Joshua's offer to put up the labor if we can put up the dough, given the
fact that Postgres is still in flux, do you think its even possible to do some sort of in-place upgrade, not knowing
what may come up when you're writing 7.6?
In other words, if we pony up and get something written now, will it need further development every time an x.y release comes up.
There is probably no question that it will need further development. However, I would imagine that once the intial grunt work is done it would be much easier to migrate the code (especially if it is continually maintained) to newer releases.
My thought process is that we would start with 7.4 codebase and as it migrates to 7.5 move the work directly to 7.5 and if possible release for 7.5 (although that really may be pushing it).
J
What I'd be curious about is how badly we compare as far as major releases
are concerned ... I don't believe we've had a x.y.z release yet that
required a dump/reload (and if so, it was a very very special
circumstance), but what about x.y releases? In Oracle's case, i don't
think they do x.y.z releases, do they? Only X and x.y?
Lord, who knows what they're up to. They do (or did) x.y.z releases (I'm using 8.1.6), but publicly they're
calling everything 8i,9i,10g yahdah yahdah yahdah.
I certainly will concede that (to me), upgrading Postgres is easier than Oracle, as I can configure, compile, install,
do an initdb, and generate an entire large DDL in the time it takes the abysmal Oracle installer to even start. Then try
to install/upgrade it on an 'unsupported' linux, like Slack...but I don't have to do anything with the data.
To a PHB/PHC (pointy-haired-client), saying 'Oracle' is like giving them a box of Depends, even though it doesn't save them
from a fire hose. They feel safe.
K, looking back through that it almost sounds like a ramble ... hopefully--------------------
you understand what I'm asking ...
I know when I was at the University, and they dealt with Oracle upgrades,
the guys plan'd for a weekend ...
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
Andrew Rawnsley President The Ravensfield Digital Resource Group, Ltd. (740) 587-0114 www.ravensfield.com
-- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com The most reliable support for the most reliable Open Source database.
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
