Jim Starkey's Thoughts on DDL

The original data definition mechanism was direct update of system
tables. This proved both scary and awkward, and a BLR-ish DYN layer was
added. When DSQL was extended to include SQL DDL, the DSQL, originally
in the client, later moved to the Y-valve, translated the SQL DLL into
dyn for interpretation. This means that for every new DDL clause we
invent, it must be added to DSQL, DYN, and the DYN interpreter.

Vulcan has move DSQL from the Y-valve to the engine. I think it's time
to stop translating SQL DDL into DYN and go directly to changes in the
internal metadata and system tables, gradually replacing much or most of
MET. This will relegate DYN to a legacy service that we can allow to
whither and die as the remaining parts of the tool set learn to express
DDL in SQL.

If we can reach agreement on this process, I suggest that proposals to
extend SQL DDL be considered this light. Doing them in the current
architecture of either Firebird or Vulcan will require about twice as
much work to go through DYN than direct handling of SQL DDL, and
probably two thirds of it will be wasted in the long run. I would
rather see work invested in revising the internals to make extensions
easier and cleaner than spent on extensions that can only be considered
throwaways in an environment we know is life limited.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376