> What is not clear for me:
> 1) Prepare statement in one transaction, transaction is committed and
> statement is run on others transaction
> 2) Metadata integrity checks (see my reply to Alex) when old versions
> are involved

I know this will upset many users/developers but...

In both of these cases, the prepared statements are invalid for new
transaction context and any use of the prepared statements should raise
an error.

(The error should not be when the new transaction is started but when
the invalid statement is used in the new transaction)

I think that it is entirely logical for a statement and transaction to
be expected to be completely valid from a database schema and data
perspective.

Therefore, if the database schema changes, then all prepared statements
which refer to invalid objects should be marked as invalid, as of this
transaction!

The key issue is that the detection logic should appropriately track the
dependencies and the "real" changes. False collisions are not
acceptable.

As both Alex and Paul have stated your suggested approach of restricting
schema changes is much too limiting.

Schema changes on a live database must be allowed, without regard the
active transactions. New transactions, as with data, should be
constrained by the new schema.


Sean