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

Hi Ajit!
Thank you very much for your work on this subject.
Your patch corrects my clumsy proposal and fixes problematic cases.
I'm reviewing it now and vote to put it in the closest commitfest and
commit.

On Thu, Aug 27, 2026 at 12:21 PM Ajit Awekar <ajitpostgres(at)gmail(dot)com> wrote:

> Hi hackers,
>
> This attached patch relies on fdw_scan_tlist to carry the new
> remote-tableoid row-identity column.
>
> fdw_scan_tlist is a targetlist describing the contents of the scan tuple
> returned by the FDW; it can be NIL if the scan tuple matches the declared
> rowtype of the foreign table, which is the normal case for a simple
> foreign
> table scan. (If the plan node represents a foreign join, fdw_scan_tlist
> is required since there is no rowtype available from the system catalogs.)
>
> A base-relation foreign scan normally fetches columns positionally: the
> scan tuple is assumed to match the foreign table's own rowtype 1:1, so
> nothing above the scan needs to know what the remote query actually
> returned.
>
> The remote tableoid doesn't fit the positional world at all - it isn't a
> column the local foreign table has, so there's no local attribute number
> for it to occupy. Reusing the ordinary tableoid system column doesn't
> work either, since that resolves locally to the foreign table's own OID,
> not the remote row's. So it has to travel as an invented pseudo-column,
> under an out-of-range attribute number - RemoteTableOidAttributeNumber,
> defined as MaxHeapAttributeNumber + 1, i.e. one past anything a real
> catalog column could ever have, so it can never collide with a genuine
> attribute - and that forces the scan onto the same explicit-tlist path
> joins already use.
>
> Please review the attached patch and let me know your comments.
>
> Thanks & Best Regards,
> Ajit
>
>

--
Regards,
Nikita Malakhov
Postgres Professional
The Russian Postgres Company
https://postgrespro.ru/