db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: Collation implementation WAS Re: Should COLLATION attribute related code go in BasicDatabase?
Date Thu, 15 Mar 2007 19:31:36 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.
> 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.


View raw message