Re: [(known) BUG] DELETE/UPDATE more than one row in partitioned foreign table

From: Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Nikita Malakhov <hukutoc(at)gmail(dot)com>, Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [(known) BUG] DELETE/UPDATE more than one row in partitioned foreign table
Date: 2026-06-10 11:22:31
Message-ID: CAPmGK15vOW11uodFuSEDcYaUxLX4egOgwGq4BZasgG_pNOa_7Q@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 10, 2026 at 2:38 PM Michael Paquier <michael(at)paquier(dot)xyz> 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Akshay Joshi 2026-06-10 11:24:22 Re: [PATCH] Add pg_get_table_ddl() to reconstruct CREATE TABLE statements
Previous Message Amit Kapila 2026-06-10 11:17:11 Re: DOCS - Add missing EXCEPT parameter description to ALTER PUBLICATION