> It would be circular if we didn't change the startup scheme. There
> are any number of ways to handle the problem:
>
> 1 Populate core system table in-memory metadata structures
> during database attachment from initialized structures
> 2 Special case core system table name resolution in the semantic
> analysis phase of the compiler
> 3 Execute SQL ddl statements declaring core system tables during
> database attachment

First I thought that 3 was just a clever way of doing 1, until I
realised that you probably meant keeping the data in the global
symbol table of the compiler, and not in the metadata module. Keeping
a metadata cache in the global symbol table is what my oracle-mode
module does :^) and that's what Netfrastructure apparently does too.

In a world view where we can have more than 1 SQL compiler, this may
not be the most optimal way to go:
- data would be duplicated between SQL compilers
- diffent systems (Oracle-mode, SQLServer-mode, etc.) have different
global namespace structures, which can evolve to be quite complex
(think packages, per-user schema, nested tables, object tables,
whatever); it wouldn't necessarilly be the best place to keep first
tier system name information.

I am not a fan of option 2, because such special casing makes the
code flow harder to follow. I think it is better to reserve code
complexity in compiler for things that add functionality to the
source language or add quality to the generated code.

Perhaps option 1, using a ddl DECLARE TABLE syntax to fill the cache
in the metadata module is a better way to go, if one wants to support
more than 1 SQL compiler: simple, clean & layered. But then again,
perhaps I am the only one who's interested in more than 1 SQL
compiler.

Just my 2c worth.

Paul