Re: partition routing layering in nodeModifyTable.c

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: partition routing layering in nodeModifyTable.c
Дата
Msg-id CA+HiwqEC2co-5R3wpgnWx0_sDdVDPhb_fuuBBSHDcPC9Hb4Gvg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: partition routing layering in nodeModifyTable.c  (Etsuro Fujita <etsuro.fujita@gmail.com>)
Ответы Re: partition routing layering in nodeModifyTable.c  (Etsuro Fujita <etsuro.fujita@gmail.com>)
Список pgsql-hackers
On Wed, Aug 7, 2019 at 12:00 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
> IIUC, I think we reached a consensus at least on the 0001 patch.
> Andres, would you mind if I commit that patch?

I just noticed obsolete references to es_result_relation_info that
0002 failed to remove.  One of them is in fdwhandler.sgml:

<programlisting>
TupleTableSlot *
IterateDirectModify(ForeignScanState *node);
</programlisting>

    ... The data that was actually inserted, updated
     or deleted must be stored in the
     <literal>es_result_relation_info->ri_projectReturning->pi_exprContext->ecxt_scantuple</literal>
     of the node's <structname>EState</structname>.

We will need to rewrite this without mentioning
es_result_relation_info.  How about as follows:

-     <literal>es_result_relation_info->ri_projectReturning->pi_exprContext->ecxt_scantuple</literal>
-     of the node's <structname>EState</structname>.
+     <literal>ri_projectReturning->pi_exprContext->ecxt_scantuple</literal>
+     of the result relation's<structname>ResultRelInfo</structname> that has
+     been made available via node.

I've updated 0001 with the above change.

Also, I updated 0002 to remove other references.

Thanks,
Amit

Вложения

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

Предыдущее
От: Konstantin Knizhnik
Дата:
Сообщение: Handling RestrictInfo in expression_tree_walker
Следующее
От: Kuntal Ghosh
Дата:
Сообщение: Re: POC: Cleaning up orphaned files using undo logs