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

From: Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>
To: Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [(known) BUG] DELETE/UPDATE more than one row in partitioned foreign table
Date: 2025-07-27 10:35:59
Message-ID: CAPmGK16Kz3zau788CvvnuzZk72Gk4Udb9KnROUdmj2ajACeRKQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 23, 2025 at 7:38 PM Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> wrote:
> I think a simple fix for this is to teach the system that the foreign
> table is a partitioned table; in more detail, I would like to propose
> to 1) add to postgres_fdw a table option, inherited, to indicate
> whether the foreign table is a partitioned/inherited table or not, and
> 2) modify postgresPlanForeignModify() to throw an error if the given
> operation is an update/delete on such a foreign table. Attached is a
> WIP patch for that. I think it is the user's responsibility to set
> the option properly, but we could modify postgresImportForeignSchema()
> to support that. Also, I think this would be back-patchable.

I noticed that this issue occurs in other cases: eg, if a foreign
table is an updatable view on a partitioned/inherited table,
non-pushed-down updates/deletes on the foreign table have the same
issue. So adding the support in postgresImportForeignSchema() is not
that simple. I feel like leaving it to the user, at least for
back-branches.

Best regards,
Etsuro Fujita

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Frédéric Yhuel 2025-07-27 10:46:44 Re: vacuumdb changes for stats import/export
Previous Message Julien Rouhaud 2025-07-27 09:19:56 Bogus bitmasking in heap2_desc