Mike Matrigali wrote:
Rick Hillegas wrote:
This is where I get confused. Are multiple collations required in a
single database? With plans for DERBY-1478 it isn't. With new
collations it isn't.
With collation per-schema it is, but should we pay overhead now for a
possible future, as long as we have a design that supports an upgrade
path to it?
I am not seeing the value in the argument for storing it once per
table vs. once per database today.
Hi Mike,
Can you expand on this? What is the overhead we're avoiding?
Thanks,
-Rick
Pushing an extra argument on every object creation for each member of
a template. Interpreting the extra argument in the object creation call.
Storage space in the conglomerate. Code to read/write the extra
metadata. The templates in the worst case are created once for each
conglomerate/index accessed in each sql statement. In best case the
templates are reused across executions of same prepared statement.
I admit all this may be small, and if we NEED it then I have no problem
it being added. I just have a problem if there is no need. I have been
burnt in the past adding stuff that I thought might be useful in the
future, so now I tend to lean toward implementing what we need today,
while making sure there is a reasonable upgrade path in the future.
If I thought today's code was making it harder for a future path that
would be a different case. For
example what if whatever way we decide to store the value of the
collation today, turns out not to work for future expansions of the
collation - and we could have gotten away with storing it once per
db vs once per table. Now we have a much bigger upgrade issue.
The system catalog implication may make this all a moot discussion, it
may be the reason we need per-schema collations. Mamta's original
design handled system catalog vs non system catalog with format id's so
there was no need for per conglomerate collations. I didn't realize
until my last message that Dan's proposal would need multiple
collations in a single db in 10.3.
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
