Re: Fix inconsistencies for v12

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

In response to

Responses

Browse pgsql-hackers by date

  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