Subject | Re: [Firebird-Architect] Schemas |
---|---|
Author | Jim Starkey |
Post date | 2009-09-24T20:53:24Z |
Leyne, Sean wrote:
initialized. As originally designed, the core metadata has a hardcoded
representation used to bootstrap access to system tables. And, worse,
system tables are (were?) by id, rather than name.
Changing the metadata bootstrap process would go a long way toward
eliminating the 31 character name limitation (another DEC artifact).
Earlier versions of Netfrastructure had 127 byte names (field, table,
schema, etc.). Falcon, Netfrastructure V3, and NimbusDB have no
limitations on name length whatsoever (and all strings are UTF-8).
--
Jim Starkey
Founder, NimbusDB, Inc.
978 526-1376
>The length of identifiers is an artifact of the way system metadata is
>> I think this is a useful feature, also considering its presence in the
>> SQL specification (IIRC, it's the only feature from the core subset of
>> SQL-92 which we don't support), but I wouldn't call it really urgent
>> (although I'd assign it a higher priority than longer-then-31-char
>> identifiers-but-without-schemas :-).
>>
>
> I disagree!
>
> "Longer-then-31-char identifiers-but-without-schemas" is an absolute priority.
>
> Length of identifiers is an issue which is independent of the schemas.
>
>
>
initialized. As originally designed, the core metadata has a hardcoded
representation used to bootstrap access to system tables. And, worse,
system tables are (were?) by id, rather than name.
Changing the metadata bootstrap process would go a long way toward
eliminating the 31 character name limitation (another DEC artifact).
Earlier versions of Netfrastructure had 127 byte names (field, table,
schema, etc.). Falcon, Netfrastructure V3, and NimbusDB have no
limitations on name length whatsoever (and all strings are UTF-8).
--
Jim Starkey
Founder, NimbusDB, Inc.
978 526-1376