Currently we have only one operator <->
In src/hnsw/options.c file there's a function HnswGetMetricKind which will determine current operator class being used with and index and detect right metric kind for usearch index using the support function pointers.
This is great as we can have only one operator which will support various distance functions, but when used out of index scope for example in SELECT statement, the operator can not automatically detect which distance function should be used.
We are currently throwing an error when <-> is used out of index lookup. We are doing this using ExecutorStart_hook the hook implementation is defined in src/hnsw/options.c void executor_hook.
This function receives QueryDesc struct, and we are currently doing regexp matching on sourceText. This approach is not covering cases when the operator will be used with ORDER BY, but there won't be an index scan.
To fix all the cases we might use plannedstmt which contains the AST of planned statement, where we can find information about the indexes and much more.
After doing this changes theres hnsw_operators_todo.sql test file. The file should be renamed to hnsw_operators.sql and included in schedule.txt file
Currently we have only one operator
<->In
src/hnsw/options.cfile there's a functionHnswGetMetricKindwhich will determine current operator class being used with and index and detect right metric kind forusearchindex using the support function pointers.This is great as we can have only one operator which will support various distance functions, but when used out of index scope for example in
SELECTstatement, the operator can not automatically detect which distance function should be used.We are currently throwing an error when
<->is used out of index lookup. We are doing this usingExecutorStart_hookthe hook implementation is defined insrc/hnsw/options.cvoid executor_hook.This function receives QueryDesc struct, and we are currently doing regexp matching on
sourceText. This approach is not covering cases when the operator will be used withORDER BY, but there won't be an index scan.To fix all the cases we might use plannedstmt which contains the AST of planned statement, where we can find information about the indexes and much more.
After doing this changes theres
hnsw_operators_todo.sqltest file. The file should be renamed tohnsw_operators.sqland included inschedule.txtfile