Hello Lester,

Wednesday, October 19, 2005, 5:47:42 AM, you wrote:

> Dmitry Yemanov wrote:

>> "Jim Starkey" <jas@...> wrote:
>>
>>>"create domain rdb$user_name varchar(128) CHARACTER SET
>>>UNICODE_FSS;",
>>
>> Strictly speaking, user names are SQL identifiers and hence they should be
>> CHAR(31). As Claudio has pointed out, we don't support longer user names
>> anyway, neither at the system tables level nor perhaps at the code level.
>> The question is whether making it consistent really breaks something. Any
>> customers have user names longer than 31 characters without anything granted
>> to them?

> I think the question should be "Do we go for full SQL2003 compliance?"
> and make thinks that are currently limited to 31 characters move to the
> 64 character limit defined there.

I don't about 64 characters, I just read the SQL Standard document
that I have and it's 128 characters. And, yes, I know it's too late
for FB2, but if Jim wants to do that in Vulcan, he has my support.
Otherwise, let's try to put it in FB 3. I hit the limit when I try to
use a more descriptive name for a table or a field, because
abbreviations do tend to resemble each other after 250 tables.

> Not sure how UNICODE is covered in that limit from the SQL standard ;)

Simple in the SQL-2003 standard, they are not defined as UNICODE, but
simple ASCII characters.

Here's the definition(found in section 5.4 of the 9075-2 document):

<SQL language identifier part> ::=
<simple Latin letter>
| <digit>
| <underscore>

<simple Latin letter> ::=
<simple Latin upper case letter>
| <simple Latin lower case letter>

<simple Latin upper case letter> ::=
A | B | C | D | E | F | G | H | I | J | K | L | M | N | O
| P | Q | R | S | T | U | V | W | X | Y | Z
<simple Latin lower case letter> ::=
a | b | c | d | e | f | g | h | i | j | k | l | m | n | o
| p | q | r | s | t | u | v | w | x | y | z
<digit> ::=
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9


And, here's the paragraphs describing how they should be managed:

[Start quote...]
1) In an <SQL language identifier>, the number of <SQL language
identifier part>s shall be less than 128.

2) An <SQL language identifier> is equivalent to an <SQL language
identifier> in which every letter that is a lower-case letter is
replaced by the corresponding upper-case letter or letters. This
treatment includes determination of equivalence, representation in the
Information and Definition Schemas, representation in diagnostics
areas, and similar uses.

NOTE 76 — The Information Schema and Definition Schema are defined in
ISO/IEC 9075-11.

3) An <SQL language identifier> (with every letter that is a
lower-case letter replaced by the corresponding upper-case letter or
letters), treated as the repetition of a <character string literal>
that specifies a <character set specification> of SQL_IDENTIFIER,
shall not be equal, according to the comparison rules in Subclause
8.2, “<comparison predicate>”, to any <reserved word> (with every
letter that is a lower-case letter replaced by the corresponding
upper-case letter or letters), treated as the repetition of a
<character string literal> that specifies a <character set
specification> of SQL_IDENTIFIER.

NOTE 77 — It is the intention that no <key word> specified in ISO/IEC
9075 or revisions thereto shall end with an <underscore>.
[...end quote]

So, basically the way Firebird handles unquoted identifiers(i.e.:
table names and field names) is correct. So, if someone argues
differently, then we can refer them to the SQL-Standard.

If we are to continue to support UNICODE for object identifiers, then
it should be 128 UNICODE characters, not just 128 bytes.

--
Best regards,
Daniel Rail
Senior Software Developer
ACCRA Group Inc. (www.accra.ca)
ACCRA Med Software Inc. (www.filopto.com)