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.
