Mulgara

When a new stringpool node is allocated (in XAStringPoolImpl.Phase.findGNode), the AVL comparator does not use the subtype ID locating the SPObject in the stringpool. If you attempt to insert a datatyped literal, and there is already a stringpool entry with an identical type ID and lexical form but different subtype ID, then the node for that existing entry is returned. For instance, if there is already an entry for "0"^^xsd:integer, you cannot insert "0"^^xsd:nonNegativeInteger -- it gets mapped to the existing "0"^^xsd:integer.

Fixing this issue would probably require modifying the comparator to use the subtype ID. This would have implications for any code that wants to take slices from the stringpool for typed literals, ignoring subtype (as I believe is the case in the XSD resolver). Also, changing the comparator would change the ordering in the stringpool, which would break backwards compatibility with previous database versions.