From: | Zhihong Yu <zyu(at)yugabyte(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: support for MERGE |
Date: | 2021-11-13 15:50:40 |
Message-ID: | CALNJ-vQeAvD+O+Xfqk6ed-AeocOj5f4TG07ooLi0=rACyhmP3A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Nov 13, 2021 at 7:41 AM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
wrote:
> On 2021-Nov-12, Zhihong Yu wrote:
>
> > +lmerge_matched:
> > ...
> > + foreach(l, resultRelInfo->ri_matchedMergeAction)
> >
> > I suggest expanding the foreach macro into the form of for loop where the
> > loop condition has extra boolean variable merge_matched.
> > Initial value for merge_matched can be true.
> > Inside the loop, we can adjust merge_matched's value to control whether
> the
> > for loop continues.
> > This would avoid using goto label.
>
> Heh, have you seen the definition of foreach() lately? I do *not* want
> to expand that anywhere. Anyway, even if we had the old foreach()
> (before commit 1cff1b95ab6d), ISTM that the goto makes the whole thing
> much clearer. For example, where would you do the
> table_tuple_fetch_row_version call that currently lies after the goto
> label but before the foreach loop starts?
>
The table_tuple_fetch_row_version() can be called before the next iteration
starts (followed by the adjustment of loop control variables).
Since you feel using goto is clearer, it is Okay to keep the current
formulation.
Cheers
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-11-13 16:28:16 | Re: ALTER TABLE DETACH PARTITION violates serializability |
Previous Message | Euler Taveira | 2021-11-13 15:45:31 | Re: Allow users to choose what happens when recovery target is not reached |