Re: [HACKERS] MERGE SQL Statement for PG11 - Mailing list pgsql-hackers

From Amit Langote
Subject Re: [HACKERS] MERGE SQL Statement for PG11
Date
Msg-id 33e09a3f-753a-3377-8a6d-574375b0f4c6@lab.ntt.co.jp
Whole thread Raw
In response to Re: [HACKERS] MERGE SQL Statement for PG11  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 2018/04/06 5:00, Andres Freund wrote:
> On 2018-04-05 11:31:48 +0530, Pavan Deolasee wrote:
>>> +   /*
>>> +    * If there are not WHEN MATCHED actions, we are done.
>>> +    */
>>> +   if (mergeMatchedActionStates == NIL)
>>> +       return true;
>>>
>>> Maybe I'm confused, but why is mergeMatchedActionStates attached to
>>> per-partition info? How can this differ in number between partitions,
>>> requiring us to re-check it below fetching the partition info above?
>>>
>>>
>> Because each partition may have a columns in different order, dropped
>> attributes etc. So we need to give treatment to the quals/targetlists. See
>> ON CONFLICT DO UPDATE for similar code.
> 
> But the count wouldn't change, no? So we return before building the
> partition info if there's no MATCHED action?

Yeah, I think we should return at the top if there are no matched actions.

With the current code, even if there aren't any matched actions we're
doing ExecFindPartitionByOid() and ExecInitPartitionInfo() to only then
see in the partition's resultRelInfo that the action states list is empty.

I think there should be an Assert where there currently is the check for
empty action states list and the check itself should be at the top of the
function, as done in the attached.

Thanks,
Amit

Attachment

pgsql-hackers by date:

Previous
From: amul sul
Date:
Subject: Re: [HACKERS] Restrict concurrent update/delete with UPDATE ofpartition key
Next
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Restrict concurrent update/delete with UPDATE ofpartition key