Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gULny-0006ps-51 for pgsql-hackers@arkaria.postgresql.org; Wed, 05 Dec 2018 01:16:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gULnw-0005mW-Jp for pgsql-hackers@arkaria.postgresql.org; Wed, 05 Dec 2018 01:16:44 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gULnw-0005k1-8z for pgsql-hackers@lists.postgresql.org; Wed, 05 Dec 2018 01:16:44 +0000 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gULnt-0005wt-Bb for pgsql-hackers@lists.postgresql.org; Wed, 05 Dec 2018 01:16:43 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id D75E4D17; Tue, 4 Dec 2018 20:16:39 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 04 Dec 2018 20:16:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paquier.xyz; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=9+ISx/3xv6qC4WB/+ZOGOAXzfye N33ZlrFg8uX08BEA=; b=j5OO/eO35QWCr+sQO2osTbClV4OTdh1Gn6/+PDv+lcg wy2IjsF2aXQGpKZ+vdIWaUvEdQp+eA24IcRlyGgeLAvm7+RNXnheOYnXXOEs33xi tBAHfGPikiKV32C5NHcNGpIHHzIzbgvlugPUFQq+VpvkB/HZOsmRi9L+ja4KF2M8 Xm1z4m1lOa2pxC3Cmg9vxS3EXcwZxW6M8rWQAOzjCJncHTAGWQaDI8yxswxXx8lZ EX9kruXChGh2cMuj3tkD93QiXliyPUskiBuo4bXhvaGWLgG7hWBugror1aFZFkW1 IjIElSmY4N0LhkkU0aVDvhdwibmFZFbhkGxqckpmoDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=9+ISx/ 3xv6qC4WB/+ZOGOAXzfyeN33ZlrFg8uX08BEA=; b=wSNMkbsn7dhY+KSUoum/cr /SH7gbgiVjpJApQbCteqMX204ArK0ZES17uuFVvGuhUNNEep+1NeYPGfXR3ku3Ew mAGquKHkTIPIcMZWCS6j6xt4gnu8CDT8rlF0US2jhQlY7bGzhPLD5eoD2ELnYV7F LNB7ILreQv4Xaxtue5jlzFVm4TqD/9Yqd80cTChr1sendIFcnh1r4mySDhVc6c9E vVDkZsc+dooAKsQL+7rxqObf8aoKi7JIeevCFeB5kYDhXjgTS0GQDJWfILMCaWIp CN7fTPWvVILHJhRbD3EpGskLG8HEnfOOHFQ87mE2jbjNNy68ZZfnwtQhB5lIhZ+g == X-ME-Sender: X-ME-Proxy: Received: from paquier.xyz (c137162.net61215.cablenet.ne.jp [61.215.137.162]) by mail.messagingengine.com (Postfix) with ESMTPA id A518410304; Tue, 4 Dec 2018 20:16:36 -0500 (EST) Date: Wed, 5 Dec 2018 10:16:33 +0900 From: Michael Paquier To: Alvaro Herrera Cc: Tom Lane , Pg Hackers , Amit Langote Subject: Re: psql display of foreign keys Message-ID: <20181205011633.GC2407@paquier.xyz> References: <23923.1543935600@sss.pgh.pa.us> <20181204184159.eue3wlchqrkh4vsc@alvherre.pgsql> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7qSK/uQB79J36Y4o" Content-Disposition: inline In-Reply-To: <20181204184159.eue3wlchqrkh4vsc@alvherre.pgsql> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --7qSK/uQB79J36Y4o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Dec 04, 2018 at 03:41:59PM -0300, Alvaro Herrera wrote: > I spent a few minutes trying to think of a way of determining which > query to use at SQL-execution time -- two CTEs, one of which would be > short-circuited ... but I couldn't figure out how. I also tried to use > the new pg_partition_tree() function, but it's useless for this purpose > because it roots at its argument table, and there doesn't seem to be a > convenient way to obtain the topmost ancestor. 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. -- Michael --7qSK/uQB79J36Y4o Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAlwHJvEACgkQnvQgOdby QH32Cg//d/rzJ4u1UDLsgehMES+luFavPBdgvqhZPy9nmush0Z8u99BeLrzmmR6t qtJLZ5ICEkxZzszqCsLc9VOh8ZRU4tL1OrChkxSSwW5GAW4B4F7ukendg6fu4X35 sNOTPs+DQJoZ5bmi0hvC+McbbpA9/SbRaGGxOycxbVRvECdhxL/NKauDC4YEhub/ SzZ4fZIg+zq+JF6eIN0moBxSe48CI5nTYT1r7DREhMGatwl1NR39BFQmjUCPC7qb CTdEQry6c5FBcasgAEHSzV33UqJ7I9WI6HsYIp6Gq/hrOLYdHrPQ42+sdwXK9fvk 9TWouGOI1pVp5TKMSuKrKPejM4fWoNLxiTF6OI4BVT8OPwh0+h8Ge5/dHKuVsqze m5V0RpAAYu0duCRHc/M+iKngIcee86lhDlBlWNi/itHLzGQnnyJTtM/0iLGZLJCl MBYwbf0FSHpM/dC4fUGc594eST8EXUKzbElejdvEsgc+779w6xBxkra7scxCguBp QQVT5Ki8Jcs6AWNWBw3ww0mnFrtUEfTHhf90UORKsMzLCEADEmCEcQh1W9DNlMi4 Nanv7oyR9rL16cNMLoOThnhFHSqJ0A3v9vf4GzKv4Vu9OjHWGqkQqcfdukqq162R y2D8AaNxGvsAsrC8r2fDFzwv0ce7OK10ZCHFDmTZkzC/cTeV6Q4= =/qIA -----END PGP SIGNATURE----- --7qSK/uQB79J36Y4o--