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 18:04:40 GMT
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.



Mime
View raw message