db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: Collation implementation WAS Re: Should COLLATION attribute related code go in BasicDatabase?
Date Thu, 15 Mar 2007 20:16:19 GMT
Rick Hillegas wrote:
> 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.
>> Thanks,
>> Dan.
> I guess I'm not understanding why we wouldn't design this generality 
> into the on-disk representation from the start. What is the 
> danger/cost/problem we're trying to avoid? Designing for the general 
> case will save us an upgrade issue later on.

So SQL does allow per-column collations, SQL Standard 11.4 <column 
definition> has a <collate clause>.


View raw message