> Yes, but don't you agree that it doesn't make sense to destroy
> the sources? Obviously, any information in the system tables
> _can_ be destroyed, but if you do so, there's no garantee that
> the DB will operate correctly... I think it's the same for the
> source code of triggers and procedures.

Its true that destroying the source is a waste of time. People
doing so to get protection for their proprietry code are
deluding themselves. However its also true that people do it,
sometimes security by obscurity is good enough.

One solution to the problem would be to stop storing object
names in compiled code. Relations have relation_ids, why dont
other objects have surrogate identifiers too?

Even without surrogate identifiers dependency tracking could
soon discover whether a domain is used in a trigger or SP. If
it is used and cannot be recompiled with a change to the domain
then the domain change would be denied.

I dont particularly want domain constraints applied to domains
used in triggers and SPs. I just want the data-type, for two
reasons...

- Its convenient

- It helps procedures to self-document - for example; here
is a variable and its type (domain) tells you that this
char(1) (or smallint or whatever) is used as a boolean.


--
Geoff Worboys
Telesis Computing