Re: psql display of foreign keys

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
Subject: Re: psql display of foreign keys
Date: 2018-12-05 16:09:54
Message-ID: 20181205160954.zkmyj7lnamebyy2v@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2018-Dec-05, Michael Paquier wrote:

> This has been mentioned on the thread where pg_partition_tree has been
> discussed:
> https://www.postgresql.org/message-id/6baeb45a-6222-6b88-342d-37fc7d3cf89a%40lab.ntt.co.jp
>
> It got shaved from the final patch for simplicity as we had enough
> issues to deal with first. Adding a pg_partition_root or a new column
> in pg_partition_tree makes sense. My guts are telling me that a
> separate function is more instinctive to use.

I agree with your guts ... you can combine them (the functions, not the
guts) to obtain the full view of the partition hierarchy just by
applying pg_partition_root() to the argument of pg_partition_tree.

I think with pg_partition_root we can rewrite the FK queries to avoid
WITH RECURSIVE with pg12 servers, but of course with a pg11 server we'll
have to keep using WITH RECURSIVE.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bossart, Nathan 2018-12-05 16:11:23 Re: Use durable_unlink for .ready and .done files for WAL segment removal
Previous Message Tom Lane 2018-12-05 16:06:48 Re: minor leaks in pg_dump (PG tarball 10.6)