Re: Fix inconsistencies for v12 - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Fix inconsistencies for v12
Date
Msg-id CAA4eK1JPBLD2BJgUygNhwKYam5b4_qo6SxXxsJ=ackGBs+fvLw@mail.gmail.com
Whole thread Raw
In response to Re: Fix inconsistencies for v12  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Fix inconsistencies for v12
List pgsql-hackers
On Mon, May 27, 2019 at 3:59 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Amit Kapila <amit.kapila16@gmail.com> writes:
> > On Sun, May 26, 2019 at 2:20 AM Alexander Lakhin <exclusion@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

Attachment

pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: [HACKERS] WAL logging problem in 9.4.3?
Next
From: Gurjeet Singh
Date:
Subject: Fix comment in pgcrypto tests