> 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/