Subject Re: [Firebird-Architect] Statement Cache [was: User name SYSDBA]
Author Jim Starkey
Leyne, Sean wrote:

>>There is never any need to invalidate compiled statements.
>Are you sure about that?
>One of the feature which Oracle has that I think would be very
>beneficial to Firebird is the ability to change the definition of any
>object (say a table) via at any time. Instead of verifying that the
>dependent objects are not in use, Oracle proceeds with the change but
>marks each of the active dependent objects as invalid, thus requiring
>the object to be recompile.
>This approach would go a long way to simplifying schema maintenance.
>As such, the ability to mark on object as invalid would be "a good
Uh, Sean, it's been that way since the GDS/Galaxy alpha in 1985. If you
check the history, you will find that Rdb/ELN (immediate precursor to
GDS/Galaxy, Interbase, and Firebird) was the first database to allow
unrestricted metadata updates which the database was running
multi-user. Before then, all database systems, Oracle, I believe,
included, did an in-place conversion requiring exclusive access to the
object in question. So it isn't a question of Firebird picking up a
useful Oracle feature but Oracle copying a useful Firebird feature.

Borland did introduce a rather stupid, unnecessary restriction on
alteration of foreign keys that has subsequently been fixed.

And, as I said before, there is no need to mark anything as invalid. A
"select *" may be obsolete after adding a new field to a table, but
executing statements are not the least bit invalid. All that is
necessary to to drop obsolete compiled statements from the cache so the
next "prepare" will force a full recompilation.


Jim Starkey
Netfrastructure, Inc.
978 526-1376