Mike Matrigali wrote:
I'll let someone else summarize. At this point I have
been convinced by Dan that his proposal is the best way
forward. And by rick and dan that we should just go
ahead and store column level metadata for the collate
info in the store, as well as in the language level
per column metadata.
The key points that convinced me are:
o Even though we are proposing a "single" collation per
database, internally we need to support 2 per database to
do the right thing for system catalogs. Once there are
2 we needed support in store to at the very least store
metadata per conglomerate.
o It looks like dan's proposal makes the runtime creation
of the collated and non-collated objects easier. I don't
understand all the places this affects, but anything that
makes this easier seems good to me.
I think some design specification or notes would be really useful for
collation. As Mike says the places where this has an impact are not well
known, starting a list on a wiki page would be good, then others could
look and ask if other areas are effected. E.g. I think the path we are
heading down is that at create table or alter table add column time the
collation for that column will be set in its DataTypeDescriptor, just
like its nullability is today. Then at bind time when that column is
referenced the collation type will be available through its DTD. But
there are a host of other character expressions, it would be good to
list these up front and how the collation will be set, rather than
discovering them one at time through coding (and missing some). E.g.
What's the defined behaviour for:
string literal
cast to character type of a character expression
trim
concatenation
etc.
Then some writeup of how store column collation information is to be
stored (along with upgrade issues) would really help cement a good
design up front.
Thanks,
Dan.
