Re: support for MERGE

On Thu, 17 Mar 2022 at 03:18, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> v16.
> On 2022-Mar-14, Japin Li wrote:
>
>> +       ar_delete_trig_tcs = mtstate->mt_transition_capture;
>> +       if (mtstate->operation == CMD_UPDATE && mtstate->mt_transition_capture &&
>> +               mtstate->mt_transition_capture->tcs_update_old_table)
>> +       {
>> +               ExecARUpdateTriggers(estate, resultRelInfo, tupleid, oldtuple,
>> +                                                        NULL, NULL, mtstate->mt_transition_capture);
>> +
>> +               /*
>> +                * We've already captured the NEW TABLE row, so make sure any AR
>> +                * DELETE trigger fired below doesn't capture it again.
>> +                */
>> +               ar_delete_trig_tcs = NULL;
>> +       }
>>
>> Maybe we can use ar_delete_trig_tcs in if condition and
>> ExecARUpdateTriggers() to make the code shorter.
>
> ... Well, the code inside the block is about UPDATE triggers, so it's a
> nasty to use the variable whose name says it's for DELETE triggers.
> That variable really is just a clever flag that indicates whether or not
> to call the DELETE part.  It's a bit of strange coding, but ...
>
>> +MERGE is a multiple-table, multiple-action command: it specifies a target
>> +table and a source relation, and can contain multiple WHEN MATCHED and
>> +WHEN NOT MATCHED clauses, each of which specifies one UPDATE, INSERT,
>> +UPDATE, or DO NOTHING actions.  The target table is modified by MERGE,
>> +and the source relation supplies additional data for the actions
>>
>> I think the "source relation" is inaccurate.  How about using "data
>> source" like document?
>
> I debated this with myself when I started using the term "source
> relation" here.  The result of a query is also a relation, so this term
> is not incorrect; in fact, the glossary entry for "relation" explains
> this:
> https://www.postgresql.org/docs/14/glossary.html#GLOSSARY-RELATION
>
> It's true that it's not the typical use of the term in our codebase.
>
> Overall, I'm -0 for changing this.  (If we decide to change it, there
> are other places that would need to change as well.)

Thanks for the detailed explanation.

--
Regrads,
Japin Li.
ChengDu WenWu Information Technology Co.,Ltd.