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
