Subject | Re: [Firebird-Architect] Multi-level name space |
---|---|
Author | Jim Starkey |
Post date | 2006-01-13T12:38Z |
Martijn Tonies wrote:
is no incompatibility -- you can still refer to you table with the
embedded dot form and it will still work. There is no problem there at
all. The problem, if it is a problem, is that the following sequence
*does* fail:
create table "hungry"."wolf" (n int);
create table "hungry.wolf" (n int);
But it fails cleanly at DDL time so there can't be any actual ambiguity
problems. So if the only cost of the compromise is that a user is
prevented from defining a table "wolf" in the schema "hungry" *and* an
unqualified table "hungry.wolf", then the compromise is a bargain indeed.
[Non-text portions of this message have been removed]
>Because "hungry.wold" was unqualified before and it should be unqualifiedMartijn, please stop and think for a moment. You aren't screwed. There
>after.
>
>The current system allows dots in delimited identifiers, you cannot say that
>if you use a dot, you're screwed.
>
>I'm all for backwards compatibility on this one.
>
>
>
is no incompatibility -- you can still refer to you table with the
embedded dot form and it will still work. There is no problem there at
all. The problem, if it is a problem, is that the following sequence
*does* fail:
create table "hungry"."wolf" (n int);
create table "hungry.wolf" (n int);
But it fails cleanly at DDL time so there can't be any actual ambiguity
problems. So if the only cost of the compromise is that a user is
prevented from defining a table "wolf" in the schema "hungry" *and* an
unqualified table "hungry.wolf", then the compromise is a bargain indeed.
[Non-text portions of this message have been removed]