http://www.sigaev.ru/misc/builtin_knngist_core-0.9.gz
http://www.sigaev.ru/misc/builtin_knngist_itself-0.8.2.gz
http://www.sigaev.ru/misc/builtin_knngist_proc-0.8.gz
http://www.sigaev.ru/misc/builtin_knngist_contrib_pg_trgm-0.8.gz
http://www.sigaev.ru/misc/builtin_knngist_contrib_btree_gist-0.8.1.gz
>>> + if (opform->oprresult == BOOLOID)
>>> + ereport(ERROR,
>>> +
>>> (errcode(ERRCODE_INVALID_OBJECT_DEFINITION),
>>> + errmsg("index ordering
>>> operators must not return boolean")));
New version allows to use boolean distance, i.e. the same operator could be used
both in WHERE and ORDER BY clauses. Now operator could present in operator
family twice, but with different StrategyNumber: as ordinary search operator (in
WHERE clause) and as an order operator (ORDER BY).
So, list of changes:
1) "pg_amop_opr_fam_index" UNIQUE, btree (amopopr, amopfamily) => "pg_amop_opr_fam_index" UNIQUE, btree (amopopr,
amopfamily,amoporder)
2) op_in_opfamily, get_op_opfamily_strategy, get_op_opfamily_properties accept one more argument, bool orderop, to
pointwhich kind of operator we need to find
3) bool OpExpr.orderop. This field is needed to correctly set SK_ORDER flags for index scan (ExecIndexBuildScanKeys
function).SK_ORDER flag points type of tree traversal algorithm to GiST core.
Introducing two fields, per Tom's suggestion, doesn't resolve following issues:
- we still need to distinguish WHERE and ORDER BY operator in ExecIndexBuildScanKey, as it done in new version of
patch
- When we execute AMOPOPID cache request we still need to check pg_amop.amorder or introduce two new indexes (amopopr,
amopfamily,amopcanwhere) and (amopopr, amopfamily, amopcanorder) and the same changes in lsyscache's functions
- If one operation could be used for both usage type then it will be good to distinguish them in consistent method.
Newversion requires to use different strategy number for each usage type.
--
Teodor Sigaev E-mail: teodor@sigaev.ru
WWW: http://www.sigaev.ru/