> 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

Reply via email to