If any serious thought is going to be given to internalizing SQL to
support SQL rather than GDML in MET, you might think about changing how
system tables are handled during start up with an eye to both
flexibility and simplicity.
Here is how I've done system startup on post-Interbase database systems:
1. System tables are broken into two categories: core and layered. The
core tables are those necessary to bootstrap references to other
tables. Layered system tables are handled like user tables but are
owned by the system. The core system are probably RDB$PAGES,
RDB$RELATIONS, RDB$FIELDS, RDB$FORMATS and RDB$RELATION_FIELDS.
2. Core system tables are prepared from SQL DDL at startup with with a
global flag indicating that internal data structures are to be built
as normal, but the effect of the DDL is not propagated to disk.
Once the core system table DDL has been processed, the engine is
capable of accessing all other tables, though it should be obvious
that various non-core system tables will have to come up first.
3. Non-core tables can be altered like user tables.
4. Core system tables can be altered with the in-memory only flag set
as long as RDB$FORMATS is itself never altered.
The result of this or similar strategy is that once implemented, it will
never be necessary to change the ODS to add or extend system tables.
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
