Re: [patch] Have psql's \d+ indicate foreign partitions - Mailing list pgsql-hackers

From Ian Lawrence Barwick
Subject Re: [patch] Have psql's \d+ indicate foreign partitions
Date
Msg-id CAB8KJ=iuD=UxMTkNb2YLrKbnE7d+fywDLR6ske4OBRG0wkFBoQ@mail.gmail.com
Whole thread Raw
In response to Re: [patch] Have psql's \d+ indicate foreign partitions  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
2022年10月27日(木) 16:12 Alvaro Herrera <alvherre@alvh.no-ip.org>:
>
> On 2022-Oct-24, Justin Pryzby wrote:
>
> > On Mon, Oct 24, 2022 at 09:44:18PM +0900, Ian Lawrence Barwick wrote:
>
> > > +                           else if (child_relkind == RELKIND_FOREIGN_TABLE && is_partitioned)
> > > +                                   appendPQExpBuffer(&buf, ", server: \"%s\"", PQgetvalue(result, i, 4));
>
> > To avoid the clutter that you mentioned, I suggest that this should show
> > that the table *is* foreign, but without the server - if you want to
> > know the server (or its options), you can run another \d command for
> > that (or run a SQL query).
>
> But 'server "%s"' is not much longer than "foreign", and it's not like
> your saving any vertical space at all (you're just using space that
> would otherwise be empty), so I'm not sure it is better.  I would vote
> for showing the server.

Indeed; my particular use-case is being able to see how the (foreign) tablesare
distributed over one or more foreign servers, so while being able to see whether
it's a foreign table or not helps, it's not all that much more disruptive to
include the identity of the server (unless the server's name is maxing out
NAMEDATALEN, dunno how prevalent that is in the wild, but it's not something
I've ever felt the need to do).

Regards

Ian Barwick



pgsql-hackers by date:

Previous
From: Dave Page
Date:
Subject: Re: Tracking last scan time
Next
From: Dilip Kumar
Date:
Subject: Re: Code checks for App Devs, using new options for transaction behavior