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

Hi Nikita,

I have added it in the commitfest:
https://commitfest.postgresql.org/patch/7211/

Requesting a review.

Thanks & Best Regards,
Ajit

On Thu, 27 Aug 2026 at 20:06, Nikita Malakhov <hukutoc(at)gmail(dot)com> wrote:

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