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 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
