Jim Starkey wrote:

> Alex Peshkov wrote:
>
>
>>Jim Starkey wrote:
>>
>>
>>
>>>Here is an updated version of the RDB$USERS tables implemented by Vulcan:
>>>
>>> static const char *creationDDL [] =
>>> {
>>> "create domain rdb$user_name varchar(128) CHARACTER SET
>>> UNICODE_FSS;",
>>>
>>>
>>
>>Porting given version of RDB$USERS into fb2, I've found a little problem
>>(not bug, but something contra-intuitive).
>>We already have
>>create domain rdb$user varchar(31) CHARACTER SET UNICODE_FSS;
>>Domain rdb$user is used in rdb$ relations, procedures, roles and
>>privileges. Creating rdb$user_name together with already existing
>>rdb$user (with same functionality - store user's name) seems strange to
>>me. Why not use already existing one?
>>I can find only one excuse for this duplication - it makes formally
>>possible to use old ODS security database ODS 11 with newer (ODS 12 or
>>13?) databases, that handle SQL identifiers according to standard. But
>>this will definitely require new version of authentication plugin
>>'security database'. Do we really need to be able to support new version
>>of plugins with old databases?
>>
>>
>
> The primary difference between RDB$USER_NAME and RDB$USER is that the
> former is 128 characters and the later 31.

Obvious difference - my question was "how much do we need it?".

> However, I don't see any
> particular benefit to having a longer field in the authentication table
> than the system tables.

Did you change your mind? A week ago you've have called suggestion to
make length of RDB$USER_NAME == 31 byte "very stupid".

> Logically, of course, it makes all the sense in
> the world. My only concern is about what hackery is in place concerning
> character/physical lengths and other international issues inside the
> system tables (as I said earlier, I make no claim to understand how it
> currently works). If someone who knows can assure use that a non-core,
> non-system flagged table referencing a core system-defined domain
> declared as varchar(31) can handle a suitable length of Russian names
> (worst case of multi-byte characters and name length), then we shouldn't
> have a problem. I just want to make sure that Mr.* Rimsky-Korsakoff's
> descendents can still attach to Firebird databases.

Sorry, can't answer this. Useful information is completely lost for me
in a good portion of thin english humor - I don't understand what did
you mean.

I don't see any serious reason to have special domain for user's name in
RDB$USERS. What's your mind?