Claudio, > To the dismay of Sean, I continue saying that while we don't declare "name > independence" and continue relying on RDB$ for some decisions, it's better > to forbit the RDB$ prefix for user objects. See, for example:
That is not want I was/am saying. I have problem with forbidding RDB$ prefix for user objects, there should be no architectural restriction limitation for this. I have a problem in saying that the RDB$ objects can't be extended by a user as their need requires. Adding additional columns, triggers or indexes to system tables should be allowed. There are existing attributes/fields within the schema structures to identify system vs. user defined objects. Further, natural schema rules prevent collisions in the names of the objects. So, there is no architectural reason why extending the existing tables/RDB$ prefix should be reserved from an architectural perspective. My position is: - restrictions are needed to prevent direct user operations from changing system schema **columns** (these columns are clearly/already identified) except through DDL syntax and user DDL privilege enforcement. - the RDB$ prefix should have no significance to the engine -- the RDB$System_Flag should be the true authority of system managed objects. Your example of the RDB$Cat Domain is a perfect example of poor thinking on the part of the engine developer at the time - changes to how gbak operates are necessary, to treat/backup user defined columns/objects separate from the system objects -- to mitigate against future ODS upgrades which might create collisions with existing defined user objects (the new system objects would always win). Sean ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
