db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Collation implementation WAS Re: Should COLLATION attribute related code go in BasicDatabase?
Date Thu, 15 Mar 2007 18:22:22 GMT


Daniel John Debrunner wrote:
> Rick Hillegas wrote:
> 
>> Daniel John Debrunner wrote:
>>
>>> Rick Hillegas wrote:
>>>
>>>> Daniel John Debrunner wrote:
>>>>
>>>>> ...
>>>>>
>>>>> - The collation type (the integer) is written into the meta-data 
>>>>> for an index just as ascending/descending is today (including the 
>>>>> btree control row, thus making the information available for 
>>>>> recovery). Collation type applies to all character columns in the 
>>>>> index.
>>>>>
>>>> This suggests that all of the columns in the index must have the 
>>>> same collation? I don't think that is powerful enough to support the 
>>>> full-blown SQL collation language, which allows you to mix 
>>>> differently collated columns in an ORDER BY clause. Why can't the 
>>>> collation type be an array of ints just as the sort direction is an 
>>>> array of booleans in IndexDescriptor?
>>>
>>>
>>> That would be more flexible, but is it required?
>>
>> I believe so. I don't see any rule which requires one collation for 
>> all of the character expressions in an ORDER BY clause. There does 
>> seem to be a rule requiring one collation for both sides of a 
>> comparison, e.g., for both sides of a < operator.
> 
> 
> I understand ORDER BY with different collations is required, but I meant 
>  are multiple collations required in a single BTREE index, which is 
> where this meta data would be stored. With the plans for DERBY-1478 it 
> isn't, with new collations it isn't, with collation per-schema it isn't, 
> so I was wondering what would trigger it? If it's not in the foreseeable 
> future or an option through SQL then I would say a simple single 
> collation will work. Future expansion could change it to be per-column 
> when required.

This is where I get confused.  Are multiple collations required in a 
single database?  With plans for DERBY-1478 it isn't.  With new 
collations it isn't.
With collation per-schema it is, but should we pay overhead now for a
possible future, as long as we have a design that supports an upgrade
path to it?
I am not seeing the value in the argument for storing it once per
table vs. once per database today.
> 
> Thanks,
> Dan.
> 
> 
> 
> 


Mime
View raw message