Re: Fix how some lists are displayed by psql \d+

From: Peter Smith <smithpb2250(at)gmail(dot)com>
To: Neil Chen <carpenter(dot)nail(dot)cz(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Fix how some lists are displayed by psql \d+
Date: 2026-01-09 01:54:33
Message-ID: CAHut+PvfgqAzi_RFhjSJgXMhZSxTqUxhGhmFvYyXsDJebd3Ftg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jan 9, 2026 at 12:19 PM Neil Chen <carpenter(dot)nail(dot)cz(at)gmail(dot)com> wrote:
>
...
> This patch looks good to me.
> However, referring to the original code implementation, I believe the initial design intention for the psql display was to make it as "compact" as possible.
> I'm not sure.. if it's worthwhile to uniformly change the display style of other items you mentioned (such as Publications) to the compact style?

Hi Neil.

Thanks for the review and the feedback.

I assume the "compactness" you are referring to is where the first
item was appearing on the same line as the list header "Partitions:".
Yes, I did recognize and consider doing the same for all lists, but it
seemed more work, and the end result would *still* have mis-aligned
lists whenever there are multiple list types (because those list
headers are of all different lengths so the indents are different).
IMO that mis-alignment would still look messy just as the current HEAD
does.

TBH, I don't know if the primary goal of the \d+ is compactness, or
readability. I chose readability. YMMV.

There might be some middle ground, where lists having just a single
item can appear on the same line as their list header. But, with lots
of different kinds of lists, all that extra compacting logic seems
overkill to me just for the sake of 1 or 2 fewer lines in the \d+
output. Again, that's why I chose the KISS approach.

Waiting for other opinions.

======
Kind Regards,
Peter Smith.
Fujitsu Australia

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Neil Chen 2026-01-09 02:17:55 Re: Optimize SnapBuildPurgeOlderTxn: use in-place compaction instead of temporary array
Previous Message Xuneng Zhou 2026-01-09 01:32:01 Re: Optimize SnapBuildPurgeOlderTxn: use in-place compaction instead of temporary array