Re: knngist - 0.8

> forward.  Tom and I laid out a technical design back in January and I
> still think it's a good one, even though I know you think it's silly.
> We may just have to agree to disagree on this point.
As I remember, there were several suggested designs:
1) 5-th boolean column (amopfamily, amoplefttype, amoprighttype, amopstrategy, 
amoporder) to point kind of operator (search or order)
   + saves one record for operator in pg_amop
   - operator could not be used in both roles
   - increase number of arguments for syscache machinery
2) 5-th combined column, which contains some kind of flag for each role
   + saves one record for operator in pg_amop
   + operator could be used in both roles
   - strategy number for operator is the same for both roles, it's unacceptable
     because GiST's consistentFn will not have information about role. GiST
     itself could distinguish them by invented SK_ORDER flag. So, this
     requires to introduce one more argument for consistentFn, while it
     already has 5 arguments.
   - increase number of arguments for syscache machinery
3) 3-rd boolean column (amopopr, amopfamily, amoporder)
   - could be two records per operator
   + operator could be used in both roles
   + strategy number could be different for different roles

All three options require to add flag of role 
op_in_opfamily/get_op_opfamily_strategy/get_op_opfamily_properties to check 
applicability of operation in current code path. First two options could do not 
change of interface of op_in_opfamily/get_op_opfamily_strategy but it will be 
needed to check actual role of operator later.

Basing on this comparison, I think, that 2) is worse and 3) is better.
-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
                                                    WWW: http://www.sigaev.ru/