On Mon, May 27, 2019 at 3:59 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Amit Kapila <amit.kapil...@gmail.com> writes: > > On Sun, May 26, 2019 at 2:20 AM Alexander Lakhin <exclus...@gmail.com> > > wrote: > >> 5. ExecContextForcesOids - not changed, but may be should be removed > >> (orphaned after 578b2297) > > > Yes, we should remove the use of ExecContextForcesOids. > > Unless grep is failing me, ExecContextForcesOids is in fact gone. > All that's left is one obsolete mention in a comment, which should > certainly be cleaned up. >
That's right and I was talking about that usage. Initially, I thought we need to change the comment, but on again looking at the code, I think we can remove that comment and the related code, but I am not completely sure. If we read the comment atop ExecContextForcesOids [1] before it was removed, it seems to indicate that the initialization of es_result_relation_info for each subplan is for its usage in ExecContextForcesOids. I have run the regression tests with the attached patch (which removes changing es_result_relation_info in ExecInitModifyTable) and all the tests passed. Do you have any thoughts on this matter? [1] /* .. * We assume that if we are generating tuples for INSERT or UPDATE, * estate->es_result_relation_info is already set up to describe the target * relation. Note that in an UPDATE that spans an inheritance tree, some of * the target relations may have OIDs and some not. We have to make the * decisions on a per-relation basis as we initialize each of the subplans of * the ModifyTable node, so ModifyTable has to set es_result_relation_info * while initializing each subplan. .. */ -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
remove_dead_code_ExecContextForcesOids_1.patch
Description: Binary data
