---------- Original Message -----------

> Anyway, for example, MS SQL allows you do this inside a transaction
> as well. You can ROLLBACK a CREATE TABLE.
>
> That being said,
>
> DELETE FROM mytable
>
> doesn't delete rows either. It deletes rows, but only for this transaction
> ;-)
>

------- End of Original Message -------

Data changes operate within the rules. Metadata changes operate on the rules themselves. My brother
also seems to believe you should be able to change the rules of a game only for yourself -- no
wonder he always won at poker. But for a database, is there a theoretical foundation for the
transactionality of metadata changes? Does Firebird have a document at least describing how its
architects felt/feel about this?

Adding a constraint means all running transactions must retroactively obey the constraint,
immediately (you can't add a constraint not obeyed elsewhere, and they started making changes
before you did -- something is going to have to give.) Except ... can they query system tables
about that constraint before you've committed? I can create a table, so long as it doesn't exist in
any other transactions. Can I delete it once they know it exists? If so, should they be allowed to
use it until they commit? [with all changes being eventually discarded?] If I add a trigger, should
it only fire within my own context? [Probably so.]

In other words, should metadata changes be restricted to single-transaction mode? You can change
the rules for poker all you like if you're the only one playing. Once in single-transaction mode,
however, doesn't it make sense to allow a fully functional rollback?

(A quick google search didn't turn up anything useful on theoretical rules for transactional
metadata/schema changes. If anyone has anything, I'd love to know.)

-Philip