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
