output columns of \dAo and \dAp - Mailing list pgsql-hackers

From Peter Eisentraut
Subject output columns of \dAo and \dAp
Date
Msg-id 2edc7b27-031f-b2b6-0db2-864241c91cb9@2ndquadrant.com
Whole thread Raw
Responses Re: output columns of \dAo and \dAp
List pgsql-hackers
I'm somewhat confused by the selection and order of the output columns
produced by the new psql commands \dAo and \dAp (access method operators
and functions, respectively).  Currently, you get

\dAo

 AM  | Operator family |       Operator
-----+-----------------+----------------------
 gin | jsonb_path_ops  | @> (jsonb, jsonb)
...

\dAo+

\dAo+
                                 List of operators of operator families
  AM   | Operator family |                Operator                 | Strategy | Purpose | Sort opfamily
-------+-----------------+-----------------------------------------+----------+---------+---------------
 btree | float_ops       | < (double precision, double precision)  |        1 | search  |
...

\dAp
                        List of support functions of operator families
  AM   | Operator family |  Left arg type   |  Right arg type  | Number |      Function
-------+-----------------+------------------+------------------+--------+---------------------
 btree | float_ops       | double precision | double precision |      1 | btfloat8cmp
...

First, why isn't the strategy number included in the \dAo?  It's part
of the primary key of pg_amop, and it's essential for interpreting the
meaning of the output.

Then there are gratuitous differences in the presentation of \dAo and \dAp.
Why does \dAo show the operator with signature and omit the left arg/right arg
columns, but \dAp shows it the other way around?

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?)

Either way some more consistency would be welcome.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Vacuuming the operating system documentation
Next
From: Peter Eisentraut
Date:
Subject: Re: [Patch] pg_rewind: options to use restore_command fromrecovery.conf or command line