MIME-Version: 1.0
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>
 <aij4NSMQYpQxtRMF@paquier.xyz>
In-Reply-To: <aij4NSMQYpQxtRMF@paquier.xyz>
From: Etsuro Fujita <etsuro.fujita@gmail.com>
Date: Wed, 10 Jun 2026 20:22:31 +0900
Message-ID: 
 <CAPmGK15vOW11uodFuSEDcYaUxLX4egOgwGq4BZasgG_pNOa_7Q@mail.gmail.com>
Subject: Re: [(known) BUG] DELETE/UPDATE more than one row in partitioned
 foreign table
To: Michael Paquier <michael@paquier.xyz>
Cc: Nikita Malakhov <hukutoc@gmail.com>,
 Jehan-Guillaume de Rorthais <jgdr@dalibo.com>,
	pgsql-hackers@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAPmGK15vOW11uodFuSEDcYaUxLX4egOgwGq4BZasgG_pNOa_7Q%40mail.gmail.com>
Precedence: bulk

On Wed, Jun 10, 2026 at 2:38=E2=80=AFPM Michael Paquier <michael@paquier.xy=
z> wrote:
> 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.

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.

Thanks for the comments!

Best regards,
Etsuro Fujita