I agree. That is a vexing problem.

You might consider the following:

* Leave the existing interface is place
* Design a "culturally compatible" interface that is free if length
limitations and has support for schemas
* Extend the remote protocol to support the expanded interface
* Let both interfaces coexist for backwards compatibility. The old
interface may see truncated field names and will not see schema
names, but for legacy applications, this isn't necessary.


Adriano dos Santos Fernandes wrote:

> Jim Starkey wrote:
>
>> Leyne, Sean wrote:
>>
>>>
>>>
>>>> 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.
>>>
>>>
>>>
>>>
>> The length of identifiers is an artifact of the way system metadata is
>> 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.
>>
>>
> IMO, there is only one "difficult" problem to increase the max. identifier length: a change in DSQL API.
>
> And together with length increase, others things should be done: change from UNICODE_FSS to UTF8 and remove hacks related to byte vs character length.
>
>
> Adriano
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>