Hi, Mark,
Mark Lewis schrieb:
> It seems that instead of maintaining a different sorting code path for
> each data type, you could get away with one generic path and one
> (hopefully faster) path if you allowed data types to optionally support
> a 'sortKey' interface by providing a function f which maps inputs to 32-
> bit int outputs, such that the following two properties hold:
>
> f(a)>=f(b) iff a>=b
> if a==b then f(a)==f(b)
Hmm, to remove redundancy, I'd change the <= to a < and define:
if a==b then f(a)==f(b)
if a<b then f(a)<=f(b)
> Data types which could probably provide a useful function for f would be
> int2, int4, oid, and possibly int8 and text (at least for SQL_ASCII).
With int2 or some restricted ranges of oid and int4, we could even
implement a bucket sort.
Markus
