Jim Starkey Wrote:

>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 DO see it as an issue of elegance, but I think there are multiple ways to
define that term. Personally, I believe that an approach that "has almost no
side effects" and "very small ripples" IS elegant.

My only concern is whether or not this scheme would preclude someone from
spending the six months to make an ANSI SQL compliant implementation in the
future, should some organization that really cares find it necessary. Maybe
the solution is to implement it DIFFERENTLY so that THIS namespace solution
could coexist with the ANSI SQL version in the future.

Specifically, if the point is to be able to set a "Standard prefix" that
applies to all the table names, then the prefix doesn't need to be called
"schema" and the delimiter doesn't need to be a dot.

So what if the delimiter were a "$", the prefix was called "Prefix", and the
syntax required the "$" at the front of the identifer to mean "insert the
prefix"?

That would give us something like:

set prefix fred;
create table foo (yada yada yada) // creates table named JUST foo
create table $foo (yada yada yada)// creates table fred$foo
select * from foo // selects from table foo
select * from $foo // selects from table fred$foo
select * from fred$foo // also selects from table fred$foo
select * from martha$foo // selects from martha$foo, if there is
one.

As far as the "hungry"."wolf" vs. "hungry.wolf" issue, I see that as a
problem only because it's a situation where a program assuming ANSI SQL
complient schemas would experience DIFFERENT behavior with the proposed
"compound name" implementation than the standard implementation.

But with this proposal, "hungry"$"wolf" vs. "hungry$wolf" would NEVER be
just "typed in" by someone expecting them to be different because they're
converting (stupid) code that works on some other database.
The fact that "$" isn't ANSI SQL compliant and is known to work differently
would force the user to think about what they're doing when they're
converting the existing code.

OK. All that said, I undersand that there are pretty high odds that there's
something really brain-dead about this idea. I'm no SQL expert, nor language
designer expert, and I'm just passing on an idea that popped into my head
this morning, so if that's the case, feel free to ignore this or shoot it
down with all the excellent reasons why it's stupid.

I'll put on my asbesdos suit just in case. <g>

Steve Summers
DRB Systems, Inc.