Feedback-ID: i0fe9450f:Fastmail
Date: Wed, 10 Jun 2026 14:37:57 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Etsuro Fujita <etsuro.fujita@gmail.com>
Cc: Nikita Malakhov <hukutoc@gmail.com>,
	Jehan-Guillaume de Rorthais <jgdr@dalibo.com>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: [(known) BUG] DELETE/UPDATE more than one row in partitioned
 foreign table
Message-ID: <aij4NSMQYpQxtRMF@paquier.xyz>
References: <20250718175314.4513c00a@karst>
 <CAPmGK15CQK-oYFMAyq+rR0rQapUHtvAGuGgY5ahERHzZ4tmC8g@mail.gmail.com>
 <20250729174852.14f23557@karst>
 <CAPmGK16v_We-k30qQaP+AARTr3n_dRg6yFuHP39sjV5uE_ne0Q@mail.gmail.com>
 <CAN-LCVMz58ukZ7ubGXiLuTeFE7wWmSwDw4URpF0q1ejzRvqbzg@mail.gmail.com>
 <CAN-LCVM2iOWkfFt22yVEGOrp-76YP3-BVKQg+A20TENkVh8o1w@mail.gmail.com>
 <CAN-LCVPgq0zfOU+BLrHnr2Sex_zndNjzWoAiONWD=R4ULQ2BAA@mail.gmail.com>
 <CAPmGK166P+ngd2ehady=_f-L4MePgBdBNxN5gi5_gSAfmV82QA@mail.gmail.com>
 <CAPmGK14KEFMTuQ1vYwWCo8SLks5rXv-56K-V+XMy4q8uQJvq1w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="L5wmk/LsQK9LT5Sb"
Content-Disposition: inline
In-Reply-To: 
 <CAPmGK14KEFMTuQ1vYwWCo8SLks5rXv-56K-V+XMy4q8uQJvq1w@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/aij4NSMQYpQxtRMF%40paquier.xyz>
Precedence: bulk


--L5wmk/LsQK9LT5Sb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Fri, Jun 05, 2026 at 08:59:17PM +0900, Etsuro Fujita wrote:
> I created the patch to add that support on top of the patch I sent in
> a previous email, which I'm attaching along with the base patch.  It's
> the same as before, except that I fixed a typo in docs pointed out by
> Michael-san off-list.

Splitting the patch set into two pieces, as of one for the
introduction of the remotely_inherited option defaulting to the
current HEAD behavior, and one for the modification of the IMPORT
FOREIGN SCHEMA, makes sense here.  A backpatch of the first patch is a
no-brainer, so as it gives a way for users to switch to the new
behavior at will.  I am however on edge regarding the wisdom of
backpatching the second patch, which would force a new behavior of the
postgres_fdw implementation for partitioned tables (based on my
read of the test with "t4") and INHERIT ("t6", "t8") depending on the
relkind or the property of the relation imported.  I can't help but
wonder why you don't take a different, slightly more conservative
approach on HEAD and the stable branches with a new option that can be
specified to the IMPORT FOREIGN SCHEMA query, to make the choice of
setting remotely_inherited for a relation imported an opt-in or
opt-out choice.

I would not object with a switch of the default behavior across major
versions, and perhaps my argument is not sound enough, but I've learnt
my share when it comes to be careful with changes like the one you may
introduce here across a minor release, particularly knowing that
remotely_inherited *can* be set on an option basis when creating a
table *or* when importing a schema.  The designs we have for these
queries allows this kind of flexibility.
--
Michael

--L5wmk/LsQK9LT5Sb
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmoo+DUACgkQnvQgOdby
QH3a1A/+Ma5yN6fjfhhHmO1HW4mxd+3lc/+zW0HVmOiwdwywubXTPmjKPaeEHqJi
hKTvzX17/o/cxsIACFWEyuxCrWwCKS3F8j3FfgQ4mnfOd20zjHfgeZxntJpBes5t
VMzIzPqhZ6Ak+KyL8nqsRxseICo/jnGN2DzQLP+6DGkBINdk5OelW7wMbGOha3JF
uOyDJfVYwG76QngzK0Qb7T3rY2B0TQwL9yGvYr5O+rsjtJFXB13CBijMD3a+3MO+
jRm5v39QXhibSJ2GnQyrUq0w2Spp273aL/u1+aAgkInj/Fm54F5LSjdRGwvDh1Li
PU1Gt3EfCR7/E0wiumtNx3UNct3uFXD1sZrUBnZvqFT+AlvCiFyUd6F9q+dPca/+
LYSCK75kkRWNeMht2zD7jmANxXdGZ/OBftzdtmx9pEDZIvh09lQ3V9k5Ak5+OVuT
XqV2Wok+kMzNMAzv2UtD0ed2liGOKtw33ESctwadBUko3FexfW4BfTl9MaRLcbME
HdWjVYFEWRJilbmJKco9PbPdDM2Gmjaws0ra/cDGo2jfpPe+8tn4oNq+C/+aZzzy
mubGQYoKPZIrkP/DiZ/UmtVdbgCQ4vmrr0Gic2gPvgcMuY3t4MDOpgGKY24+Y0Wt
4f6f8eCPV6oUFd/4K37buCyRQb4hb1gjN7weLcL2mlCq6Kh+7Uo=
=Wqxd
-----END PGP SIGNATURE-----

--L5wmk/LsQK9LT5Sb--