From: | Ian Lawrence Barwick <barwick(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [patch] Have psql's \d+ indicate foreign partitions |
Date: | 2022-10-31 12:13:25 |
Message-ID: | CAB8KJ=iuD=UxMTkNb2YLrKbnE7d+fywDLR6ske4OBRG0wkFBoQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2022年10月27日(木) 16:12 Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2022-10-31 12:22:03 | Re: Code checks for App Devs, using new options for transaction behavior |
Previous Message | Dave Page | 2022-10-31 11:36:51 | Re: Tracking last scan time |