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
notbe 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  +
operatorcould be used in both roles  - strategy number for operator is the same for both roles, it's unacceptable
becauseGiST's consistentFn will not have information about role. GiST    itself could distinguish them by invented
SK_ORDERflag. 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
inboth 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/