Re: support for MERGE

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Zhihong Yu <zyu(at)yugabyte(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: support for MERGE
Date: 2021-11-13 15:41:42
Message-ID: 202111131541.knkewwxtdt4u@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"If you have nothing to say, maybe you need just the right tool to help you
not say it." (New York Times, about Microsoft PowerPoint)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-11-13 15:42:25 Re: Inconsistent error message for varchar(n)
Previous Message Alvaro Herrera 2021-11-13 15:34:37 Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display