>>>>> "Tom" == Tom Lane <t...@sss.pgh.pa.us> writes:
>> distance_orderable now returns true/false depending on the opclass, >> not just on the amcanorderbyop field. In order to do this, I've >> added an optional amproperty function to the AM api, which if it >> exists, gets first dibs on all property calls so it can override the >> result as it sees fit. Tom> Hmm, seems like for that case, it'd be easier to look into pg_amop Tom> and see if the opclass has any suitably-marked operators. I thought about that, but it seemed like it could get painful. The planner is working forwards from a known operator and matching it against the index column, whereas we'd have to work backwards from the opfamily, and there's no good existing index for this; in the presence of binary-compatible types, I don't think even amoplefttype can be assumed (e.g. a varchar column can be ordered by pg_trgm's <-> operator which is declared for text). So it'd have to be the equivalent of: get index column's opclass oid look it up in pg_opclass to get opfamily for r in select * from pg_amop where amopfamily=? and amoppurpose='o' if r.amoplefttype is binary-coercible from the index column's type then return true As opposed to what I have now, which is: get index column's opclass oid look it up in pg_opclass to get opfamily/opcintype result = SearchSysCacheExists4(AMPROCNUM, ...) (in theory this could produce a false positive if there's a distance function but no actual operators to reference it, but I think that's the opclass author's issue) -- Andrew (irc:RhodiumToad) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers