"Ann W. Harrison" <aharrison@...> wrote:

>
> What is being proposed is a change to the current behavior.

IMO, this discussion has very little to do with the statement cache. I don't
know why Sean has raised it here, but if we proceed, could we rename the
subject line?

> When a
> referenced object is changed, any compiled instances of the referencing
> objects would be marked as requiring recompilation ad the modification
> would succeed. When the referencing objects were invoked, they would
> be recompiled and errors caused by the change would be discovered.

Would you expect us to always return an error for a invalid object being
invoked or its recompilation is attemped automatically?

> In the case of changing a field definition, existing - running -
> instances of the object would could continue to run unchanged, and most
> of the recompilations of referencing objects would occur without error.
> However, if an object were deleted or changed in an incompatible way,
> the damage caused would not be discovered until some time later when the
> referencing objects failed to compile.

Correct. And I agree such a hidden error could make some people unhappy. One
real world example: after a programming error made within one of the kernel
procedures, about 80% of the schema objects became invalid. It took 4 hours
to recompile them (automated iterations based on a dependency graph) on a
dual PIII machine. In this particular case, I'd prefer to treat an error as
a show-stopper :-)

> On the other hand, SQL schemas tend to be very interrelated with
> procedures referencing views that reference procedures and tables with
> triggers that reference other views... At the moment, making a
> significant change is a real pain. What was, in 1985, a reasonably
> simple thing - splitting a table to create two better normalized tables
> and creating a view with the old table name - could easily require
> deleting half the views, procedures, constraints, and triggers in a
> database.

You're right. Sigh. That's why we're looking for alternatives.


Dmitry