> Changing gbak so it backs up user enhancements to the system tables is just > programming, and restoring them after the base table are created isn't hard, > but both go against the V3 goal of shutting users out of system space.
It depends on your view/definition of "system space" or "system objects". As long as I can't directly or insert/delete rows of an RDB$ table or change "system" columns, or modifying system triggers and indexes, where is the harm in adding columns and triggers to an RDB$ table? Would that mean that development effort to restrict column access would be required? Yes Is there a risk to the developer is looking to extend system tables (depend on schema definition)? Yes, but that is for the developer to weigh? The ability to control access/visibility to rows and columns is a common requirement which is even appearing in the SQL Standard. So, by thinking about the "problem" from the perspective of solving this requirement, the issue of controlling access to "system objects" would also be solved. Sean ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
