From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Amit Langote <amitlangote09(at)gmail(dot)com> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: partition routing layering in nodeModifyTable.c |
Date: | 2020-10-13 16:30:28 |
Message-ID: | be90708f-9717-fb37-9cc1-d2482f7e4230@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 | Content-Type | Size |
---|---|---|
v17-0001-Include-result-relation-index-in-ForeignScan-for.patch | text/x-patch | 11.7 KB |
v17-0002-Remove-es_result_relation_info.patch | text/x-patch | 37.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2020-10-13 16:33:49 | Re: lost replication slots after pg_upgrade |
Previous Message | Fujii Masao | 2020-10-13 16:30:06 | Re: Add a description to the documentation that toast_tuple_target affects "Main" |