db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject QL
Date Thu, 15 Mar 2007 20:46:22 GMT
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 

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.


View raw message