Mamta Satoor wrote:
What I am proposing is to change the comparable method from type 1 to type
2. The reason for this is comparable method for character types should also
check the collation type and derivation while deciding whether the method
should return true or false. But since the collation information is not
associated with TypeId, we need to pass the TypeDescriptors of both the
types that need to be compared. In order to do this, I propose the
comparable method to change as follows
boolean comparable(
DataTypeDescriptor leftType,
DataTypeDescriptor rightType,
boolean forEquals,
ClassFactory cf);
This change would require that all the implementation of TC change and all
the callers of this method should change too.
I spent some time looking at this approach and it seems pretty well contained: a
search for "comparable" in the codeline shows that aside from the TypeCompiler
classes themselves, only a few other files would be affected. I tried to think
some of alternative approaches but none seemed as contained as the one you
suggest here.
----
On a completely different note, while looking at the relevant classes I noticed
that we instantiate the non-collator character types (ex. SQLChar) in the
"getNull()" method of TypeId. Do you have plans to update that piece of code to
account for collator types? Are any changes needed there? I searched the wiki
page for "TypeId" but nothing came up.
And similarly, we instantiate the non-collator character types in the
XMLSerialize() method of iapi/types/XML.java. While XML values themselves are
not orderable/comparable with any other values (and thus collation should not be
a problem), the result of an XMLSERIALIZE operator is a normal SQL character
value, which can be compared. So will the code in XML.XMLSerialize() have to be
updated to account for collation? My guess is that XMLSERIALIZE can be
characterized in the same way as the CHAR and VARCHAR functions (number 6 on the
wiki page):
[XMLSERIALIZE] behavior can be defined as similar to CAST ie, the result
character string of [XMLSERIALIZE] will have the same collation as current
schema's character set. The collation derivation will be implicit.
Does that sound right?
Sorry if that's a tad off-topic...
Army
