Re: State of Beta 2

> 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 - jd@commandprompt.com - http://www.commandprompt.com
The most reliable support for the most reliable Open Source database.