As a squeaky fly on the wall ...

I think this same thought (as Arno's, that is) is likely what prompted E.F. Codd to not only
require that relational database systems present system catalogs as relations that could be
manipulated in exactly the same manner as everything else, but to also note that it would
be "really nice" (not an exact quote) if they could be updated as well.

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.)

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?

On occasion I've needed to, say, change the domain of several fields at once, across many tables --
being able to use the relational facilities I'm accustomed to in order to do this beats the heck
out of issuing individually crafted statements. I fully expect constraints on the system catalog to
prevent me from mucking up the metadata tables too badly, just as the DDL statements would. Less
syntax, more semantics?

Then again, my wishing star has heard a lot from me about wanting DDL to be entirely
transactional ...

-Philip


---------- Original Message -----------
From: "Arno Brinkman" <firebird@...>

> If every possible action is put in a nice SQL DDL statement this should be
> good, but i think many thirth party programs use the system tables for
> actions that aren't possible at all with DDL. Changing a NOT NULL field to a
> NULLable field for example.
> I often set the default collation of a database which also isn't possible
> with a DDL command.
>
> Regards,
> Arno Brinkman
> ABVisie

------- End of Original Message -------