Re: Psql patch to show access methods info

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, David Steele <david(at)pgmasters(dot)net>, Michael Paquier <michael(at)paquier(dot)xyz>
Subject: Re: Psql patch to show access methods info
Date: 2019-09-18 14:04:40
Message-ID: 20190918140440.GA28323@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2019-Sep-18, Alexander Korotkov wrote:

> On Tue, Sep 17, 2019 at 9:01 PM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:

> > I think \dAf is just as critical as \dAo; the former lets you know which
> > opfamilies you can use in CREATE INDEX, while the latter lets you know
> > which operators would be helped by such an index. (But, really, only if
> > the opfamily name is printed in \d of the index, which we currently
> > don't print unless it's non-default ... which is an omission that
> > perhaps we should consider fixing).

> I think you have a point. Will add \dAf command to the patch.

Great, thanks.

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 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.

Thanks

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2019-09-18 14:34:17 Re: allow online change primary_conninfo
Previous Message Robert Haas 2019-09-18 14:04:05 Re: Minimal logical decoding on standbys