Re: partition routing layering in nodeModifyTable.c

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: partition routing layering in nodeModifyTable.c
Дата
Msg-id be90708f-9717-fb37-9cc1-d2482f7e4230@iki.fi
обсуждение исходный текст
Ответ на Re: partition routing layering in nodeModifyTable.c  (Heikki Linnakangas <hlinnaka@iki.fi>)
Ответы Re: partition routing layering in nodeModifyTable.c  (Amit Langote <amitlangote09@gmail.com>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: Add a description to the documentation that toast_tuple_target affects "Main"
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: lost replication slots after pg_upgrade