Re: Fix inconsistencies for v12

On Mon, May 27, 2019 at 3:59 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
> > On Sun, May 26, 2019 at 2:20 AM Alexander Lakhin <exclusion(at)gmail(dot)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