Arno Brinkman wrote:

>> 2. Schemas are undeclared, just used (this is topic for debate, folks)
>>
>>
>
>Ofcourse i want easy a list of schema's already present in the database.
>Also avoid using almost simular schema's due typos by different DBA's.
>create table financial.invoice (...)
>create table financiel.invoiceitems (...)
>
>

I don't really object to requiring schemas to be declared, but unless
there is some intrinsic benefit, it strikes me as make-work that would
mostly serve to annoy users.

>
>
>> 3. A qualified table name is represented in the system tables as
>> <schema>.<tablename> as in "myschema.mytable"
>>
>>
>
>What about:
>create table "myschema.mytable" ()
> and
>create table "myschema"."mytable" ()
>
>

They would be indistinguishable, which isn't exactly the end of the
world. If somebody wants to go out of his way to introduce ambiguity,
well, that's what he's going to do. With luck, we'll figure out a way
to make that fail on odd numbered releases and work on even numbered ones.

>
>
>
>
>>Almost nothing changes except the max length of table names and the name
>>matching rules in the BLR and SQL compilers.
>>
>>It seems too simple. What am I missing?
>>
>>
>
>Adding RDB$SCHEMA_NAME (to stay consistent) to RDB$RELATIONS
>Adding something like RDB$SCHEMAS (RDB$SCHEMA_NAME VARCHAR(xx) NOT NULL PRIMARY KEY, CREATOR
>VARCHAR(31) DEFAULT CURRENT_USER)
>
>
>

Not sufficiently backwards compatible. It would require that every
query against system tables be rewritten. It also would allow utilities
work work against old and new versions. It's the obvious way to handle
it (sans RDB$, of course) if we were starting over scratch, and also the
way I handled the issue in Netfrastructure. But the backwards
compatibility problem should make it a non-starter for Firebird.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376