Re: psql display of foreign keys

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: psql display of foreign keys
Date: 2019-02-26 22:27:57
Message-ID: 20190226222757.GA31622@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2019-Feb-04, Michael Paquier wrote:

> pg_partition_root() has not made it to the finish line yet, still it
> would have been nice to see a rebase, and the patch has been waiting
> for input for 4 weeks now. So I am marking it as returned with
> feedback.

Thanks for committing pg_partition_root ... but it turns out to be
useless for this purpose. It turns out that we need to obtain the list
of *ancestors* of the table being displayed, which pg_partition_tree
does not easily give you. So I ended up adding yet another auxiliary
function, pg_partition_ancestors, which in its current formulation
returns just a lits of OIDs of ancestor tables. This seems generally
useful, and can be used in conjunction with pg_partition_tree():

alvherre=# select t.* from pg_partition_tree(pg_partition_root('pk11')) t
join pg_partition_ancestors('pk11', true) a on (t.relid = a.relid);
relid | parentrelid | isleaf | level
pk | | f | 0
pk1 | pk | f | 1
pk11 | pk1 | t | 2
(3 filas)

(A small tweak is to change the return type from OID to regclass.
Docbook additions missing also.)

Anyway, given this function, it's possible to fix the psql display to be
as I showed previously. Patches attached.

Álvaro Herrera
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment Content-Type Size
v3-0001-pg_partition_ancestors.patch text/x-diff 2.7 KB
v3-0002-fix-psql-display-of-FKs.patch text/x-diff 17.9 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Paul Ramsey 2019-02-26 22:29:59 Re: Allowing extensions to supply operator-/function-specific info
Previous Message Tom Lane 2019-02-26 22:19:01 Re: Allowing extensions to supply operator-/function-specific info