I got several suggestions to include ordering operator for tsvector to aim 
grouping, union and except etc.

I wrote silly comparing function (byte to byte with some optimizations), but I 
wondered that for using operator < in order clause its need to declate B-tree 
opclass for type:

regression=# select  a from test_tsvector order by a;
ERROR:  could not identify an ordering operator for type tsvector
HINT:  Use an explicit ordering operator or modify the query.

I see in
backend/utils/cache/typcache.c near line 169:

         if ((flags & TYPECACHE_LT_OPR) && typentry->lt_opr == InvalidOid)
         {
                 if (typentry->btree_opc != InvalidOid)
                         typentry->lt_opr = 
get_opclass_member(typentry->btree_opc,InvalidOid, BTLessStrategyNumber);
         }

So, I must declare b-tree opclass for tsvector. Why?
My supposition is to guarantee that operator < is really 'less-than' one. Is it?




-- 
Teodor Sigaev                                  E-mail: teodor@sigaev.ru

Thu, 25 Mar 2004 17:44:39 +0300
Teodor Sigaev <teodor@sigaev.ru>
< operator for user-defined types
Teodor Sigaev <teodor@sigaev.ru> writes:
> So, I must declare b-tree opclass for tsvector. Why?
> My supposition is to guarantee that operator < is really 'less-than'
> one. Is it?

Exactly.  We used to assume that any operator named '<' would be
suitable for sorting, but it's a lot safer to assume that an operator
associated with a b-tree opclass behaves in the right way.  Also there
are some optimizations possible as a result.  (It turns out that the
sorting code will end up using the comparison support function for the
opclass, and not the operator per se, because that way we only need one
function call per comparison.  Using the operator, we'd often need two
calls.)

			regards, tom lane

Thu, 25 Mar 2004 10:29:28 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: < operator for user-defined types 