Re: (A) native Windows port

On Tuesday 09 July 2002 06:20 pm, Peter Eisentraut wrote:
> The problem in an extensible system such as PostgreSQL is that virtually
> every feature change is reflected by a change in the structure of the
> system catalogs.  It wouldn't be such a terribly big problem in theory to
> make the backend handle these changes, but you'd end up with a huge bunch
> of

> if (dataVersion == 1)
>   do this;
> else if (dataVersion == 2)
>   do that;

Ok, pardon me while I take a moment to braindump here.  And Peter, you of all 
people caused this braindump, so, 'hold on to your hat' :-).

You know, it occurs to me that we are indeed an Object RDBMS, but not in the 
conventional sense.  Our whole system is object oriented -- we are extensible 
by the data and the methods (functions) that operate on that data. In fact, 
the base system is simply a set of objects, all the way down to the base data 
types and their functions. So the problem jells down to this:

How does one upgrade the method portion of the object, bringing in new object 
data if necessary, while leaving non-impacted data alone?  Is there a way of 
partitioning the method-dependent object data from the non-object data?  This 
would require a complete system catalog redesign -- or would it?  

Can such a migration be object-oriented in itself, with the new version 
inheriting the old version and extending it.... (like I said, I'm 
braindumping here -- this may not be at all coherent -- but my stream of 
consciousness rarely is [coherent]).  Can our core be written/rewritten in 
such a way as to be _completely_ object driven? Someone steeped a little 
better in object theory please take over now....

Or am I totally out in left field here?
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11