Re: Collation order for btree-indexable datatypes

> I am planning to fix this by ensuring that all these operations agree
> on an (arbitrarily chosen) sort order for the "weird" values of these
> types. What I'm wondering about is whether to insert the fixes into
> 7.1.1 or wait for 7.2. In theory changing the sort order might break
> existing user indexes, and should therefore be avoided until an initdb
> is needed. But: any indexes that contain these values are likely broken
> already, since in fact we don't have a well-defined sort order right now
> for these values.

> What I'm inclined to do is force consistency of the comparison operators
> now (for 7.1.1) and then remove "current time" for 7.2, but perhaps it'd
> be better to leave the whole can of worms alone until 7.2. Comments
> anyone?

Assuming that the changes are reasonably safe, I think you're
right. What parts of the changes would require an initdb, would new
functions need to be added or the index ops need to change or would
it be fixes to the existing functions (if the latter, wouldn't a recompile
and dropping/recreating the indexes be enough?)