Re: partition routing layering in nodeModifyTable.c - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: partition routing layering in nodeModifyTable.c
Date
Msg-id be90708f-9717-fb37-9cc1-d2482f7e4230@iki.fi
Whole thread Raw
In response to Re: partition routing layering in nodeModifyTable.c  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: partition routing layering in nodeModifyTable.c  (Amit Langote <amitlangote09@gmail.com>)
List pgsql-hackers
On 13/10/2020 19:09, Heikki Linnakangas wrote:
> One little idea I had:
> 
> I think all FDWs that support direct modify will have to carry the
> resultRelaton index or the ResultRelInfo pointer from BeginDirectModify
> to IterateDirectModify in the FDW's private struct. It's not
> complicated, but should we make life easier for FDWs by storing the
> ResultRelInfo pointer in the ForeignScanState struct in the core code?
> The doc now says:
> 
>> The data that was actually inserted, updated or deleted must be
>> stored in the ri_projectReturning->pi_exprContext->ecxt_scantuple of
>> the target foreign table's ResultRelInfo obtained using the
>> information passed to BeginDirectModify. Return NULL if no more rows
>> are available.
> 
> That "ResultRelInfo obtained using the information passed to
> BeginDirectModify" part is a pretty vague. We could expand it, but if we
> stored the ResultRelInfo in the ForeignScanState, we could explain it
> succinctly.

I tried that approach, see attached. Yeah, this feels better to me.

- Heikki

Attachment

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Add a description to the documentation that toast_tuple_target affects "Main"
Next
From: Bruce Momjian
Date:
Subject: Re: lost replication slots after pg_upgrade