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
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 |