Claudio Valderrama C. wrote:

>However, you are offering now an ugly hack to implement a feature just for
>having less work. I think this is unacceptable.
>
>Sincerely: why don't you make a list of all changes that need to be done to
>implement the feature in a more decent way instead? True, it won't be coded
>this weekend, but after FB3 merging is complete, with your guidance, people
>will start working on it even if 70 files have to be changed. And it will be
>extensible, elegant and unambiguous.
>
>
>

I don't think the utility of separate schema and name fields justifies
the cost. What is the benefit of separate fields? Let's see? It
allows us to sort by "schema, name". It also means that a quoted
identifier can't masquerade as a schema qualified name. But I think
that's about it. You know I regard elegance in high regard, but I don't
see it here. All we're talking about is name of things and whether the
first and last names are stored in a single field or two. Which you
pick depends on what you're going to do with it. We use metadata names
for three things. First, we use names for symbol resolution during
compilation. Would the code be significantly different storing the names
as two fields instead of one? No, not much at all. Second, we use
metadata names as join terms. Any significant difference here? No.
And finally, we use metadata names to report on things. Yes, it would
be more convenient to be able to select and sort by either schema or
object name or both. But is it worth the cost.

I don't see the issue as one of elegance. I see it as whether or not
the feature is implemented. The concatenation model has almost no side
effects other than increasing object name size (which we need to do
anyway), could be implemented in a week, and would have very small
ripples. The alternative, essentially a redesign of the system tables,
would probably take six months. And ironically, to support backwards
and forwards compatibility, would end up emulating 100% of the
concatenation model through updatable views.

I think multi-level name space is a very important feature that we need
badly. That's why I favor the simpliest possible solution. The
alternative is too expensive to implement, and it just won't ever get done.

Let's look at the evolution of the discussion. Dmitry needed names for
monitoring tables that wouldn't conflict with user tables. I suggested
an ugly prefix. I said with was a nature use for multi-level name
spaces. He agreed, but said that was too hard to do in our lifetime. I
thought about it and came up with a scheme that everyone agree was
simple, worked, and satisfied compatibility requirements. Then things
got crazy. People who hours before didn't think we needed namespaces at
all now wanted three levels. Then Dmity pushed for four (three pushing
and one pulling). Then we wasted a day arguing whether a fool could
define and reference a single object into two ways (answer: Yes, and so
what?). None of this had much to do with cost and benefit. In this
case, what you call elegance I call trying to solve problems we don't have.

I'd rather have concatenated names and use the resources that would have
been used to redesign and reimplement the system tables to finish the
DDL, implement the UPGRADE verb, replace yacc/bison with a recursive
descent parser, finish the compiled statement cache, add filtersets,
implement a flexable multi-role model, finish the Interbase gateway, and
replace the SQL API. Each of these is more imporant and cheaper than
the delta between the concatenation and multi-field alternatives for
multi-level name spaces.