Feedback-ID: i0fe9450f:Fastmail
Date: Thu, 11 Jun 2026 07:25:28 +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: <ainkWN3s-12__fpo@paquier.xyz>
References: 
 <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>
 <aij4NSMQYpQxtRMF@paquier.xyz>
 <CAPmGK15vOW11uodFuSEDcYaUxLX4egOgwGq4BZasgG_pNOa_7Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="qCDWWtIhTNIKFcLS"
Content-Disposition: inline
In-Reply-To: 
 <CAPmGK15vOW11uodFuSEDcYaUxLX4egOgwGq4BZasgG_pNOa_7Q@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/ainkWN3s-12__fpo%40paquier.xyz>
Precedence: bulk


--qCDWWtIhTNIKFcLS
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 10, 2026 at 08:22:31PM +0900, Etsuro Fujita wrote:
> On Wed, Jun 10, 2026 at 2:38=E2=80=AFPM Michael Paquier <michael@paquier.=
xyz> wrote:
>> 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.
>=20
> I agree that we should take a more conservative approach especially on
> the stable branches, and I think it's a good idea to add the option to
> IMPORT FOREIGN SCHEMA for that, so I will update the patch as such in
> the next version.

Cool, thanks.
--
Michael

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

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

iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmop5FgACgkQnvQgOdby
QH3o/A//S2c7U+6yufQ3oRlmjDImxJQpRsbCoO8F2umTLFEpvD/0QfOZcTNibIFL
L2CgImzcNi45gQsFne33VDiSqcneIzlfBZ/Z0Z0kvXqZUr57F/VcFacAtaAa+WoG
rm569MCS8a8lAdrcJj8gIF4kuOKKYvtcm8p/M1dWhbqunlDkx41LRN9INRynr4E2
wz0uE4TVqhSlt2rpqvh+fqF78bHCq+C0L2IkMtMXSAMgz3G6au5A7JAIuTOzGbK5
FbFxDtDiIhW69f2GiB54A612w36lIdLdgcUgnwQXvd98EKAXlNu3hrdfp3X15cmj
JkoK+2H4OLKGv/98VEQkzp7OG33xP6Z/0p/VLrbcExfM3ETSyGq1ByQDM2vZ9XZG
r4xnurQVqEVpbikaHliWieeQAkOu3Dnz3SGmbXEvOvg1zxAKRVJ0JcCIHYQQjFl7
euO0kcDQZpXNHmhJ0HRE87v5jJ3Ut5iWYytPCLl+djhJTg6A7bJU20KQfuqDNOYA
Bk2aRgMs3PqbMPoWQFtl12+e0VHjem5euJPyGM5Kv4V3ViOd8UO/FjTndVUZJBf4
GtT/6kqVydZrt/OwyRmN7PyMyNAnsqVIJrwO8DEt5Fp1GqHlzuj6aS6aasCLroQQ
zq90hIshF43peFooap5xNQOxUQQGlZWZi12ANmEbBf0y/E2mf1Q=
=/t+u
-----END PGP SIGNATURE-----

--qCDWWtIhTNIKFcLS--