Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iAt28-0006Io-NB for pgsql-hackers@arkaria.postgresql.org; Thu, 19 Sep 2019 09:47:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iAt27-0001mB-L6 for pgsql-hackers@arkaria.postgresql.org; Thu, 19 Sep 2019 09:47:27 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iAt27-0001lz-8C for pgsql-hackers@lists.postgresql.org; Thu, 19 Sep 2019 09:47:27 +0000 Received: from mail-pg1-x542.google.com ([2607:f8b0:4864:20::542]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iAt24-0007OH-Un for pgsql-hackers@postgresql.org; Thu, 19 Sep 2019 09:47:26 +0000 Received: by mail-pg1-x542.google.com with SMTP id 4so1539920pgm.12 for ; Thu, 19 Sep 2019 02:47:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:message-id:to:cc:subject:from:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=fdhB0I6Okfy6j04fLLi+3cCU2Bmtk2YCF5U6YfXtF5c=; b=lGTDnS/PbrDGs6LXSUT91d9eICVQAXB8V8yEAxRwfiY97gUS9tay+A7GXCma5fajDH NhUojPVOfzdHPTpr0++O9Fe8WQI6L9HTWkYiHQ3UnK7F1a0PoS/cD5C6/P76SGu3vlWl Y4+SsShS6tI2hD08WU9wmKV4czt58QhB4p3XMXujsI/Mt/JplJpoIdihBJZPwCnjN1r5 mEt6tqWxlUzmTgpvmFQ7kp5OD6exk2sjFny1Pcuxoal13W/HTpTuFb/YrPcL1j8JjnqU U+LAS5DSAN6Zdwk/RfEWWbgJo1zpkb9h/v48En2gl9z3buI1n86ruylW40d+FswhiPm0 i5dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:message-id:to:cc:subject:from:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=fdhB0I6Okfy6j04fLLi+3cCU2Bmtk2YCF5U6YfXtF5c=; b=Ou1NjqiTcyBFR8FNtvbnSSm+8apiStV1PnXge0Knkmi+BQaj3tStlmHY9AmFQuyTyy rgCG404tmdSwiV1U9+6yBJsSbxy6tnIYgH2Axq4PbWw48H6sQqHdBRhJmC1RRrkqI3BT AwTKYTgWG8MciBRPiYMCR4UvUkCjY92QnhG46XaqG6THmM/GHG3WYj03EnRLwFGx4AEV csg9jWQAQAJ3Da8T5w6nU2XTIFcc9CLsWVRgl3dyfy+aABGXFFhlue6VZvoFh28fwiFy 64AkvfousXek9oLYLhGuF5dtQNHqqfEsk1f68qbjtNW/wo3M5k2ERgEQai8jhp6s5myl NIVg== X-Gm-Message-State: APjAAAXrvV23+nCUpbLnvwtNw/VHuRCarmFIRVziyDLSOiPBGOnpIhzN 6CGdKh8RAvWPvG90IyqzzNo= X-Google-Smtp-Source: APXvYqw6oT/3ATBLpEKJHMfvgGwUwDPI6p6hJ+t7VnNIVSapIiySApQ5CjRgc5bqnKtqcrhDJtr47Q== X-Received: by 2002:a65:4781:: with SMTP id e1mr8311757pgs.386.1568886442062; Thu, 19 Sep 2019 02:47:22 -0700 (PDT) Received: from localhost (w204177.dynamic.ppp.asahi-net.or.jp. [121.1.204.177]) by smtp.gmail.com with ESMTPSA id 127sm7236818pgi.46.2019.09.19.02.47.18 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 19 Sep 2019 02:47:21 -0700 (PDT) Date: Thu, 19 Sep 2019 18:47:08 +0900 (Tokyo Standard Time) Message-Id: <20190919.184708.25203401.horikyota.ntt@gmail.com> To: alvherre@2ndquadrant.com Cc: a.korotkov@postgrespro.ru, andres@anarazel.de, n.gluhov@postgrespro.ru, thomas.munro@gmail.com, pgsql-hackers@postgresql.org, david@pgmasters.net, michael@paquier.xyz Subject: Re: Psql patch to show access methods info From: Kyotaro Horiguchi In-Reply-To: <20190918140440.GA28323@alvherre.pgsql> References: <20190918140440.GA28323@alvherre.pgsql> User-Agent: Mew version 6.5 on Emacs 22.2 / Mule 5.0 =?iso-2022-jp?B?KBskQjpnGyhCKQ==?= / Meadow-3.01-dev (TSUBO-SUMIRE) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hello. FWIW.. At Wed, 18 Sep 2019 11:04:40 -0300, Alvaro Herrera wrote in <20190918140440.GA28323@alvherre.pgsql> > I think in order for this feature to be more complete "\d index" should > show the opfamily name, also, even when it's the default one. (Let's > not put the opfamily when it's the default in "\d table", as we do when > the opfamily is not default; that would lead, I think, to too much > clutter.) > > > > On the other hand, from a user perspective, what you really want to know > > > is: what opfamilies exist for datatype T, and what operators are > > > supported by the opfamily I have chosen? The current patch doesn't > > > really help you find that out. I have thought that several times. > I hope that in some future somebody will contribute towards this, which > I think is more important (from users POV) than the below one: > > > > I think \dAp isn't terribly informative from a user perspective. The > > > support procs are just an opfamily implementation detail. > > > > I've expressed my opinion regarding \dAp in [1]. In my observations, > > some advanced users can write btree/hash opclasses in pl/* languages. > > This doesn't require knowledge of core developer. And they may find > > \dAp command useful. What do you think? > > I have never tried or had the need to do that. I'll take your word for > it, so I have no objection. > > I do wonder if \? is going to end up with too much clutter, and if so do > we need to make \? show only the most important commands and relegate > some others to \?+ ... however, going over the existing \? I see no > command that I would move to \?+ so \dAp would be alone there, which > would be pretty strange. So let's forget this angle for now; but if > psql acquires too much "system innards" functionality then I say we > should consider it. Before the fact that usable slot of two-letter commands is almost filled, my poor memory rejects to remember the commands that is used infrequently.. ctrl-I suggests many two-or-three letter meta commands but I can't tell what is the command I'm searching for. \? shows too many commands as you mentioned. If something like "\? | grep index" works, it would be helpful. regards. -- Kyotaro Horiguchi NTT Open Source Software Center