> -----Original Message----- > From: Leyne, Sean [mailto:s...@broadviewsoftware.com] > Sent: Domingo, 30 de Marzo de 2014 14:31 > To: For discussion among Firebird Developers > > 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.
While we don't have the right solution and the time for doing it properly, at least user domains with rdb$ should be stopped. The other object types don't present a similar problem that I'm aware of. > 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. AFAIK, you can put triggers on sys tables and they last until the last attachment finished. When the db is loaded again, those triggers do not load. I don't know if that changed recently, but was this way since I remember. Can you explain why do you need to alter system tables? What other engines allow this operation, MySql, SqlServer, Oracle > - 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 In theory, yes. > - 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). In most cases, gbak takes into account the sys flags, but I don't know how it would behave with additional user defined fields for sys tables. C. ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
