Fwd: Problem while updating a foreign table pointing to a partitioned table on foreign server

I sent this about two and a half hours ago, but it appears that gmail
delivery failed to this list, so I resent it:

On Wed, Oct 1, 2025 at 11:13 PM Daniil Davydov <3danissimo(at)gmail(dot)com> wrote:
> On Fri, Nov 16, 2018 at 6:35 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> writes:
> > > [ fix-foreign-modify-efujita-2.patch ]
> >
> > Um ... wow, I do not like anything about this. Adding a "tableoid = X"
> > constraint to every remote update query seems awfully expensive,
> > considering that (a) it's useless for non-partitioned tables, and
> > (b) the remote planner will have exactly no intelligence about handling
> > it. We could improve (b) probably, but that'd be another big chunk of
> > work, and it wouldn't help when talking to older servers.
> >
> > (Admittedly, I'm not sure I have a better idea. If we knew which
> > remote tables were partitioned, we could avoid sending unnecessary
> > tableoid constraints; but we don't have any good way to track that.)
>
> About point (a) :
> Actually, we can request tableoid to be included into the result row (for
> the ForeignScan node) and then check whether tableoid matches the oid
> of the foreign table. If not - we will know that tuple is stored in a
> partition.
>
> Thus, we will request tableoid only when we will know that we are
> scanning foreign partitioned table.

Sorry, I don't fully understand you here, but I think that when
updating a foreign table via ForeignModify, we 1) should retrieve
tabloid from the remote if the foreign table points to a remote
partitioned/inherited table, and 2) should not otherwise, to avoid
useless data transmission. Is that possible?

> > I wonder whether we'd be better off thinking of a way to let FDWs
> > invent additional system column IDs for their tables, so that
> > something like a remote table OID could be represented in the
> > natural way as a Var with negative varattno.
>
> May I ask you to tell me more details? As far as I understand, if
> postgres_fdw doesn't use direct modify, it will hardcode query like
> this anyway :
> appendStringInfoString(buf, "DELETE FROM ");
> deparseRelation(buf, rel);
> appendStringInfoString(buf, " WHERE ctid = $1");
>
> At the moment when we set the ctid in this way, the situation inevitably
> moves towards an error.
>
> Are you suggesting using another condition for the WHERE clause in
> this case (based on the new "remote table oid" column)?

No, he is mentioning how we should manage tableoid retrieved from the
remote during query execution (from ForeignScan node to ModifyTable
node), and yes, if we addressed this, we could modify the deparser
code to add a "tableoid = X" constraint to the WHERE condition when
updating a remote partitioned/inherited tale.

Best regards,
Etsuro Fujita