Re: Show comments in \dRp+, \dRs+, and \dX+ psql meta-commands

From: Matheus Alcantara <matheusssilv97(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Show comments in \dRp+, \dRs+, and \dX+ psql meta-commands
Date: 2026-02-20 12:58:45
Message-ID: 57917e97-c9df-4829-9b86-914b131023d3@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 16/02/26 11:57, Fujii Masao wrote:
> Hi,
>
> The psql meta-commands that list publications, subscriptions, and extended
> statistics (\dRp+, \dRs+, and \dX+) do not display their associated comments,
> whereas other \d meta-commands do. This makes it inconvenient to view
> these objects together with their descriptions.
>
> I'd like to propose the attached patch to improve \dRp+ and \dRs+ so
> they include comments for publications and subscriptions. The patch also
> extends the \dX meta-command to accept the + option, allowing comments
> for extended statistics to be shown when requested. Thoughts?
>

Thanks for working on this. I miss the \dX+ feature when reviewing
your other path on improving documentation for CREATE TABLE LIKE.

The code seems correct to me and it's working as described, I don't
any special comments.

> BTW, while working on this, I also noticed that \dRs+ currently outputs nearly
> all subscription parameter settings (for example, [1]), whereas other
> \d meta-commands tend to show only a subset of details. So, as new parameters
> (or columns in pg_subscription) are added, the number of columns in \dRs+
> will continue to grow, which could make the output harder to use.
> I think it might be better to exclude parameter settings to keep
> the output manageable.
>
> As just idea, it may be sufficient for \dRs+ to display commonly used
> identifying information such as Conninfo and Description in addition to
> the fields shown by \dRs (Name, Owner, Enabled, and Publication).
> Other details (e.g., Failover) could still be viewed directly in
> pg_subscription.
> Thought?
>

Yeah, I agree that the output can will be harder to read when the
number of parameters (or columns) in pg_subscription grow, but since
most of these columns are visible only on verbose mode (+) it doesn't
seems an issue IMHO. In the future if the output columns grow too much
we can rethink this, but for now I think that it's fine.

+1 for the patch. (I've reviewed the v2 attached by Jim on [1])

[1]
https://www.postgresql.org/message-id/82b25785-0dc1-46d6-93ac-ce385a3a0bfc%40uni-muenster.de

--
Matheus Alcantara
EDB: https://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey Borodin 2026-02-20 13:09:23 Fix XLogFileReadAnyTLI silently applying divergent WAL from wrong timeline
Previous Message Junwang Zhao 2026-02-20 12:49:03 Re: some validate_relation_kind() tidying