Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jhcQJ-0006v7-HX for pgsql-hackers@arkaria.postgresql.org; Sat, 06 Jun 2020 17:15:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jhcQH-0000Ek-Bi for pgsql-hackers@arkaria.postgresql.org; Sat, 06 Jun 2020 17:15:57 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jhcQH-0000Ed-4L for pgsql-hackers@lists.postgresql.org; Sat, 06 Jun 2020 17:15:57 +0000 Received: from [64.147.123.35] (helo=wforward5-smtp.messagingengine.com) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jhcQE-000217-7L for pgsql-hackers@postgresql.org; Sat, 06 Jun 2020 17:15:56 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailforward.west.internal (Postfix) with ESMTP id B96E66F4 for ; Sat, 6 Jun 2020 13:15:42 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sat, 06 Jun 2020 13:15:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=tgYmul oao0qmtA2pkF8bGr4ddpZrRFtW7h1hwlRAIRg=; b=sVoe6D92xyoMSHEfRzqGlB 56cgGLvjYxgiPjZIL4E/mdJ4zA+ZpErwNo9PCursOiSqKcFcY0EyliM7YcHI20YQ Wxd7yne0iaGhS2PeouQVk7C7a6YLv6sencGKY00obTB6v2NzenYxpyyg8LmgOQhI xaUaigmokN2mOw0Jcbv/LZ9ZbiW+O491iz7cA9pqAGBZ8Z6+8uUCi4UPuI6WRK5I ZFaLwgeDTcn2WWW/y2skUtCMxIumimlG6JgZSiAoK1kXXlhaPoHGQAfAqShpkoIb G/v9XmeIoj+1Cd010hG2Mb4YBfrXIzXYEGgk8oT43yHqf35YkL++xa++dW1GvRSg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeghedgudduhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhephffuvfhokffffgggtgfgsehtje ertddtfeejnecuhfhrohhmpefrvghtvghrucfgihhsvghnthhrrghuthcuoehpvghtvghr rdgvihhsvghnthhrrghuthesvdhnughquhgrughrrghnthdrtghomheqnecuggftrfgrth htvghrnheptdevjedtfefgtddvieejfeekveekhfehjedvleegtedvueduheehkedttdef leffnecuffhomhgrihhnpedvnhguqhhurggurhgrnhhtrdgtohhmnecukfhppeelfedrvd egfedrkedvrddvgeeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi lhhfrhhomhepphgvthgvrhdrvghishgvnhhtrhgruhhtsedvnhguqhhurggurhgrnhhtrd gtohhm X-ME-Proxy: Received: from april.pezone.net (p5df352f6.dip0.t-ipconnect.de [93.243.82.246]) by mail.messagingengine.com (Postfix) with ESMTPA id 43674328005D for ; Sat, 6 Jun 2020 13:15:41 -0400 (EDT) From: Peter Eisentraut Subject: output columns of \dAo and \dAp To: pgsql-hackers Organization: 2ndQuadrant Message-ID: <2edc7b27-031f-b2b6-0db2-864241c91cb9@2ndquadrant.com> Date: Sat, 6 Jun 2020 19:15:40 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 64.147.123.35 (deferred) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk 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