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. However, I don't see any
particular benefit to having a longer field in the authentication table
than the system tables. 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.
*