output columns of \dAo and \dAp

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: output columns of \dAo and \dAp
Date: 2020-06-06 17:15:40
Message-ID: 2edc7b27-031f-b2b6-0db2-864241c91cb9@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2020-06-06 17:48:57 Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line
Previous Message Magnus Hagander 2020-06-06 16:38:52 Re: Vacuuming the operating system documentation