Christopher Kings-Lynne wrote:
>
> > Whether the default DROP behavior should be CASCADE, RESTRICT, or the
> > current laissez-faire behavior remains to be debated ;-). The spec
> > is no help since it has no default: DROP *requires* a CASCADE or
> > RESTRICT option in SQL92. But I doubt our users will let us get away
> > with changing the syntax that way. So, once we have the CASCADE and
> > RESTRICT options implemented, we'll need to decide what an unadorned
> > DROP should do. Opinions anyone?
>
> Hmmm...an unadorned drop could remove the object without RESRICTing it or
> CASCADEing it. Hence, if there are objects that depend on it, the object
> will be removed anyway, and dependent objects will not be touched.
We could mark the objects(and their dependent objects) as *INVALID*.
They would revive when reference objects revive in the world of *name*s.
regards,
Hiroshi Inoue