From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Fix inconsistencies for v12 |
Date: | 2019-05-26 22:29:34 |
Message-ID: | 10570.1558909774@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
However, the full context of the mention is
/*
* call ExecInitNode on each of the plans to be executed and save the
* results into the array "mt_plans". This is also a convenient place to
* verify that the proposed target relations are valid and open their
* indexes for insertion of new index entries. Note we *must* set
* estate->es_result_relation_info correctly while we initialize each
* sub-plan; ExecContextForcesOids depends on that!
*/
which makes one wonder if the code to twiddle
estate->es_result_relation_info during subplan init is dead code. If so
we probably ought to remove it, as it's surely confusing. If it's not
dead, then this comment ought to be updated to explain the surviving
reason(s), not simply deleted.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-05-27 01:43:30 | Re: Confusing error message for REINDEX TABLE CONCURRENTLY |
Previous Message | Tom Lane | 2019-05-26 22:23:48 | Rearranging ALTER TABLE to avoid multi-operations bugs |