Rick Hillegas wrote:
Thanks, Mike. This overhead seems pretty small to me. It's hard for me
to predict whether this is useful generality or over-design.
In the SQL standard, collations can be declared per column. That
affects index descriptors. In addition, via CASTs, collations can be
declared per sortable expression in an ORDER BY clause. That affects
the sorter. I'm not the person scratching this initial itch. I just
want to register my instinct to design-in the generality up front. I
think this has two advantages:
1) It will remove an upgrade issue later on when someone wants to
implement more of the SQL collation support.
2) It generally lowers the barrier to implementing more of the standard.
Regards,
-Rick
I am just not sure how comfortable I feel forcing an upgrade issue on a
developer for a particular feature that is not their itch. Mamta is
trying to solve single collation database problem, not full SQL
collation support.
Your suggestion may get us more there, not arguing that. But a solution
shorter along an agreed upon direction seems fine to me, and I would not
hold up a developer contribution that did that. If the community feels
that
4 new classes is ok, but 4 new types is not the right direction then
it is reasonable to work with the community to get the direction right.
I am waiting on Dan's reply as I think there are SYSTABLES and/or
SYSCOLUMNS metadata changes necessary that haven't been discussed. If
so I think these are actually more upgrade work than the store ones
(I am not sure, I know exactly how to do the store upgrade ones - no
idea what is involved in SYSCOLUMNS/SYSTABLES upgrades). A real
advantage of original proposal to have new format ids was I think there
was no upgrade necessary. I still don't really understand the upgrade
ramifications as the current proposal only affects newly created
databases, so in theory there is no upgrade per se. But it may mean
that runtime code needs to handle multiple versions of metadata.
