unordained wrote:

>As views are not always updatable, even in theory, I imagine he was afraid to make it a
>requirement -- system tables exposed into the database namespace might act as views, and not be
>updatable for logical reasons. (Note: as I recall, Firebird does not allow you to update any multi-
>table view, even if it could be theoretically updated.)
>

Trivial views are automatically updatable, but the updates semantics for
any view can be specified by a trigger;

>
>In any case, exposing the entire system catalog, and making it updatable, should be the most
>flexible way of providing users with a mechanism to make metadata changes, whereas (instead!)
>providing a language construct for every possible change seems ... prone to failure?
>
>
>

That was once my opinion as well. We argued long and hard over the
issue at DEC. The Rdb/VMS guys argued that active system tables were
confusing, ill-defined, restrictive, and required, in general, too high
a level of competence on the part of users. In the end, we defined a
common DDL language, which Rdb/ELN implemented with active system tables.

Interbase was born in a world with three contending standards QUEL, SQL,
and the DEC DML language. Layering the DDL languages (note plural) on
active system tables. GDEF (aka dudley) implemented a rich DDL language
that covered all database features. A number of utilities implemented
SQL DDL for the small subset of the product that could be expressed in
standard SQL.

When I looked back at active system tables a few years ago, I concluded
that they hadn't withstood the test of time. The original DDL language
has all but been abandoned, supplanted by SQL DDL. That's OK, SQL won.
But the SQL DDL implementation hasn't tracked the product. As you and
others have pointed out, there are DDL transformations that can't be
expressed in SQL DDL.

In my mind, this is not an argument in favor of active system tables but
an argument against. If active system tables had not been there as a
safety net, the SQL DDL implementation would have evolved to cover all
product features. Over the long run, the net effect of active system
tables is degradation of DDL processing.

All Netfrastruture system tables are read-only to all but the system
itself. Netfrastructure has a single complete DDL language processor
embedded in the engine. In processing of developing Netfrastructure,
I've also taken a fresh look at DDL usage for both development and
application upgrade in situ, and use a different approach to the problem
that has proven extremely convenient.

I don't have a clue on how to convince an open source project to
consider an idea that isn't present in Holy Scripture. There are
interesting problems to solve and the talent to solve them, but
innovation and leadership apparently aren't roles accepted by open
source projects.

While we're on the subject of Holy Scripture, please keep in mind that
while Codd originated the idea of relational databases, he surrounded
the idea with so much hocus pocus that acceptance was delayed by a good
half decade, and when push came to shove, he really didn't know beans
about software.