Re: output columns of \dAo and \dAp

On 7/7/20 6:09 PM, Alexander Korotkov wrote:
> On Sun, Jun 7, 2020 at 12:34 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)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.
>
> +1 for checking consistency of amoplefttype/amoprighttype in opr_sanity.sql
>
>> I agree that \dAo ought to be showing amopstrategy;
>
> I agree that the strategy and purpose of an operator is valuable
> information. And we probably shouldn't hide it in \dAo. If we do so,
> then \dAo and \dAo+ differ by only "sort opfamily" column. Is it
> worth keeping the \dAo+ command for single-column difference?
>
>> moreover that ought
>> to be much higher in the sort key than it is.
>
> Do you mean we should sort by strategy number and only then by
> arg types? Current output shows operators grouped by opclasses,
> after that cross-opclass operators are shown. This order seems to me
> more worthwhile than seeing all the variations of the same strategy
> together.
>
>> 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.
>
> +1
>
>> 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.
>
> +1 for rename "Left arg type"/"Right arg type" to "Registered left
> type"/"Registered right type".

From the RMT perspective, if there is an agreed upon approach (which it
sounds like from the above) can someone please commit to working on
resolving this open item?

Thanks!

Jonathan