Thanks for the patch Amit.
I was wondering whether the same duplicate result rels issue can arise
for es_root_result_relations and es_result_relations. But I think for
inserts, es_root_result_relations is NULL, and for updates, these two
lists always have distinct set of relations. So this issue might not
be there for these two lists.
So what the patch does, looks good to me. One minor thing :
+ * Since we're newly creating this ResultRelInfo, add it to
+ * someplace where explain.c could find them.
I think above, instead of keeping the comment specifically for
explain.c, we should make it more general. The list is also used by
ExecGetTriggerResultRel(). (There, this duplicate relation issue does
not come up because it only uses the first one out of them).
I think the name es_tuple_routing_result_rels that you chose, sounds good.
Thanks
-Amit
On 6 February 2018 at 08:08, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote:
> On 2018/02/06 10:48, Amit Langote wrote:
>> When working on this, I wondered if the es_leaf_result_relations should
>> actually be named something like es_tuple_routing_result_rels, to denote
>> the fact that they're created by tuple routing code. The current name
>> might lead to someone thinking that it contains *all* leaf result rels,
>> but that won't remain true after this patch. Thoughts?
>
> While I'm waiting to hear some opinion on the renaming, I updated the
> patch to clarify this in the comment about es_leaf_result_relations.
>
> Thanks,
> Amit
--
Thanks,
-Amit Khandekar
EnterpriseDB Corporation
The Postgres Database Company
