>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>> distance_orderable now returns true/false depending on the opclass,>> not just on the amcanorderbyop field. In order
todo this, I've>> added an optional amproperty function to the AM api, which if it>> exists, gets first dibs on all
propertycalls 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_amopTom> and see if the opclass has any
suitably-markedoperators.
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)
