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.
Regards,
-Rick
