Vulcan - Restructuring DSQL

From Jim Starkey on the Firebird Development List 5th January 2004

DSQL is being restructured around two central classes: DStatement and CStatement. DStatement represents a statement instance and is returned as the "handle" for the dsql statement. DStatement holds state information about a dsql statement. All semantic properties of the statement is held in CStatement (compiled statement). One of these days CStatement will become a cached compiled statement, shared by many statement instances or just sitting around hogging memory.

Netfrastructure, Inc., has graciously donated a symbol manager to the Firebird project. The symbol manager is obscurely named SymbolManager. It has three main entrypoints, eaching passing in a string (const TEXT*). findSymbol returns either a symbol or a null. getSymbol always returns a symbol, adding it to the table if necessary. The symbols returned by findSymbol and getSymbol are upcased. findString and getString are parallel to these, but are case sensitive. A single symbol manager is allocated during construction of the Database object and is destroyed by its destructor. There are wrapper methods in Database (getSymbol and findSymbol) so nobody needs to see the symbol manager. With acquisence from the Type Police, I've taken the liberty of adding a SYMBOL to fb_types.h to indicate that a string has been symbolized.

The class dsql_str will be going away.

The process is more fun that being run over by a truck.