Re: psql \dh: List High-Level (Root) Tables and Indexes

From: Sadeq Dousti <msdousti(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Greg Sabino Mullane <htamfids(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: psql \dh: List High-Level (Root) Tables and Indexes
Date: 2025-02-24 08:07:09
Message-ID: CADE6LvheLMAZBP3TdaX9XSJdHF7qv0W6wkYeON_bQJjSjfJxyw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dear all,

I'm grateful for taking your time and providing various solutions!

Personally, I like Tom's idea of using N better:

* It can stand for "not a partition member" or "no partitions", and does
not provide any new terminology.
* It can be combined with various commands \dN, \dtN (or \dNt), \dNi
(or \diN), without causing confusion with existing command (e.g., \dn)
* While capitalization of N might seem arbitrary, it can be acceptable
as it's "negating" some concept

About other suggestions:

* While "a" (adult) and "e" (elders) are adorable, they introduce new
terminologies that are not widely known to the Postgres community. Being
super pedantic, an adult is always a child of some parent, and an elder
must always have one or more children. In addition, \da and \det already
exists.

* Using \pset: As Tom said, plus I think explicit is better than
implicit. Consider some DBA (or their colleague) adding this \pset into
.psqlrc, and then forget about it.

* Using \dP 0: The command \dP is already used to show partitioned
tables, and the default behavior (i.e., not \dPn) is to only show the
roots of the partition. What I'd like is to show roots as well as
non-partitioned tables.

If there are no hard objections, I'll proceed with adding the N letter
to \d commands.

Best Regards,
Sadeq Dousti

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bertrand Drouvot 2025-02-24 08:46:12 Re: Remove wal_[sync|write][_time] from pg_stat_wal and track_wal_io_timing
Previous Message Tender Wang 2025-02-24 08:00:32 Re: Anti join confusion