Leyne, Sean wrote:

>
> I brought it up, because Jim said there would never be a need to mark
> cached statements as invalid -- which would not be true if this new
> feature were to be implemented.

Actually, that's not the case in general. Even if we allowed all
metadata changes, regardless of their effect on dependent object, only
dropping tables, views, and procedures and changing procedure parameters
would actually invalidate compiled statements.

This is where Jim went back to the original design and the idea of table
formats. A compiled statement references a particular table format and
the system maintains a history of formats so it can recreate an old
format for an old request.

>>> 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.
>
> I think we need to look at the tradeoffs.
>
> In one case, you can apply any schema change while the database is
> running and all the objects will re-validated as necessary. This will
> make almost all developers very happy.

Non-destructive changes already work, as far as I know. There are some
changes that require a delete/replace (e.g. changed a field to disallow
nulls or replacing a table with a view). Would it be sufficient to find
ways to make the delete and replace a single operation and leave the
safety checking in place?

>
> In the other case, if a developer does something 'stupid'/untested the
> impact of the schema change could be 'unfortunate'. This will make some
> people unhappy.

It could be catastrophic and people would be irate.

Regards,


Ann