Re: partition routing layering in nodeModifyTable.c

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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

In response to


Browse pgsql-hackers by date

  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"