Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> I'm also wondering whether this is fully correct. Would it be possible for the
> argument types of the operator/function to differ from the left arg/right arg
> types? (Perhaps binary compatible?)
pg_amop.h specifies that
* The primary key for this table is <amopfamily, amoplefttype, amoprighttype,
* amopstrategy>. amoplefttype and amoprighttype are just copies of the
* operator's oprleft/oprright, ie its declared input data types.
Perhaps it'd be a good idea for opr_sanity.sql to verify that, since
it'd be an easy thing to mess up in handmade pg_amop entries. But
at least for the foreseeable future, there's no reason for \dAo to show
amoplefttype/amoprighttype separately.
I agree that \dAo ought to be showing amopstrategy; moreover that ought
to be much higher in the sort key than it is. Also, if we're not going
to show amoppurpose, then the view probably ought to hide non-search
operators altogether. It is REALLY misleading to not distinguish search
and ordering operators.
The situation is different for pg_amproc: if you look for discrepancies
you will find plenty, since in many cases a support function's signature
has little to do with what types it is registered under. Perhaps it'd be
worthwhile for \dAp to show the functions as regprocedure in addition to
showing amproclefttype/amprocrighttype explicitly. In any case, I think
it's rather misleading for \dAp to label amproclefttype/amprocrighttype as
"Left arg type" and "Right arg type", because for almost everything except
btree/hash, that's not what the support function's arguments actually are.
Perhaps names along the lines of "Registered left type" and "Registered
right type" would put readers in a better frame of mind to understand
the entries.
regards, tom lane