Re: transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

On Wed, May 17, 2017 at 7:42 PM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> On Wed, May 17, 2017 at 6:04 PM, Amit Langote
> <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>> targetRelInfo should instead be set to mtstate->rootResultRelInfo that was
>> set in ExecInitModifyTable() as described above, IOW, as follows:
>>
>> /* Partitioned table. */
>> if (mtstate->rootResultRelInfo != NULL)
>> targetRelInfo = mtstate->rootResultRelInfo;
>
> Ah, I see. Thank you. Fixed in the attached.

Here's a post-pgindent rebase.

Also, I discovered a preexisting bug that is independent of all this
inheritance stuff. COPY in the batch optimisation case was failing to
capture transition tuples. I thought about sending a separate patch
but this patch already has a regression test that covers it so I've
included it here. It's this hunk:

@@ -2872,7 +2872,8 @@ CopyFromInsertBatch(CopyState cstate, EState
*estate, CommandId mycid,
* anyway.
*/
else if (resultRelInfo->ri_TrigDesc != NULL &&
- resultRelInfo->ri_TrigDesc->trig_insert_after_row)
+ (resultRelInfo->ri_TrigDesc->trig_insert_after_row ||
+ resultRelInfo->ri_TrigDesc->trig_insert_new_table))
{
for (i = 0; i < nBufferedTuples; i++)
{

--
Thomas Munro
http://www.enterprisedb.com