Subject | Re: [Firebird-Architect] Multi-level name space |
---|---|
Author | Jim Starkey |
Post date | 2006-01-12T22:56:43Z |
Arno Brinkman wrote:
this problem now. But we do, and the best compromise will be the best
solution.
and tools working. Storing a concatenated name is backward compatible,
addresses the problem, and hasn't been yet shown to introduce even worse
problems (I'm holding my breath here).
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376
>Assuming we've declared a system table with schema's (which seems useful in many aspects). Now theNo good way at all. If I had been smarter in 1982, we wouldn't have
>question is how can we make a reference between RDB$RELATIONS and the RDB$SCHEMAS tables?
>
>
this problem now. But we do, and the best compromise will be the best
solution.
>>>Adding RDB$SCHEMA_NAME (to stay consistent) to RDB$RELATIONSToo late for that now. We need to keep existing programs, utilities,
>>>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.
>>
>>
>
>That's right it requires a major rewrite of the system table queries.
>Wouldn't it be better if internally was worked with RDB$RELATION_ID then?
>
>
>
and tools working. Storing a concatenated name is backward compatible,
addresses the problem, and hasn't been yet shown to introduce even worse
problems (I'm holding my breath here).
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376