Chris Cleveland <cclevel...@dieselpoint.com> writes:
> Can anyone tell me why my index access method isn't seeing an order_by
> ScanKey when there is a query with an ORDER BY clause that uses an operator
> that the access method supports?
Hmm, you have
> CREATE OPERATOR pg_catalog.<<=>> (
> FUNCTION = rdb.test_sort_match,
> LEFTARG = record,
> RIGHTARG = rdb.TestSort
> );
> CREATE OPERATOR CLASS rdb_ops DEFAULT FOR TYPE record USING rdb AS
> OPERATOR 1 pg_catalog.<===> (record, rdb.userqueryspec),
> OPERATOR 2 pg_catalog.<<=>> (record, rdb.testsort) FOR ORDER BY
> pg_catalog.float_ops;
> sql = "CREATE FUNCTION rdb.test_sort_match(rec record, testsort
> rdb.TestSort) RETURNS bool IMMUTABLE STRICT PARALLEL SAFE LANGUAGE c AS
> 'MODULE_PATHNAME', 'dummysort_match_wrapper';",
> requires = [DummySortSpec]
So <<=>> returns a bool, not anything that float_ops would apply to.
You might think that that should result in an error, but not
per this comment in opclasscmds.c:
* Ordering op, check index supports that. (We could perhaps also
* check that the operator returns a type supported by the sortfamily,
* but that seems more trouble than it's worth here. If it does not,
* the operator will never be matchable to any ORDER BY clause, but no
* worse consequences can ensue. Also, trying to check that would
* create an ordering hazard during dump/reload: it's possible that
* the family has been created but not yet populated with the required
* operators.)
regards, tom lane
