On Tue, 23 May 2000, Chris Bitmead wrote:
> Well, you've laid out a whole lot of rules here. I understand what those
> rules are, but I don't see the logical purpose for having such a set of
> rules.
>
> It appears you've got two separate inheritance mechanisms that interact
> in strange ways. Which inheritance scheme that gets activated depends on
> whether you use tablename or tablename*. Why not invent a few more
> inheritance mechanisms, then you can have tablename% and tablename&,
> then there can be some more rules for how they interact? I don't
> understand why you want to have these kinds of semantics. Does it have
> precedent in some programming language?
A database is capable of more flexibility than a programming language with
regard to how it can store objects. A database it not constrained by
hardcoded runtime and compilation dependencies like objects in a programming
language. Changing the data structure of a program means reprogramming then
restarting the program. If made right, a database can evolve its classes
without ever going offline. I think there are some differences and so I don't
see programming language precedents being so relevent.
I'm just proposing things to see if we don't over look some possibilities.
Under my ideas here, UNDER can be implemented more like to spec (maybe
exactly). INHERIT can pickup the Postgres extensions until a standard
covers it too.