Re: support for MERGE

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 02:23:52
Message-ID: CALNJ-vSVzY+v2mQU=0ObkJ1JNork3Q_iCfjAZCQUAXuQ3M81nQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 12, 2021 at 9:58 AM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
wrote:

> Here's a new version. Many of the old complaints have been fixed;
> particularly, the handling of partitioned tables is now much cleaner and
> straightforward. Amit Langote helped considerably in getting this part
> to shape -- thanks for that. Amit also helped correct the EvalPlanQual
> behavior, which wasn't quite up to snuff.
>
> There are a few things that can still be improved here. For one, I need
> to clean up the interactions with table AM (and thus heapam.c etc).
> Secondarily, and I'm now not sure that I really want to do it, is change
> the representation for executor: instead of creating a fake join between
> target and source, perhaps we should have just source, and give
> optimizer a separate query to fetch tuples from target.
>
> What I did do is change how the target table is represented from parse
> analysis to executor. For example, in the original code, there were two
> RTEs that represented the target table; that is gone. Now the target
> table is always just the query's resultRelation. This removes a good
> number of ugly hacks that had been objected to.
>
> I'll park this in the January commitfest now.
>
> --
> Álvaro Herrera Valdivia, Chile —
> https://www.EnterpriseDB.com/
> "Cómo ponemos nuestros dedos en la arcilla del otro. Eso es la amistad;
> jugar
> al alfarero y ver qué formas se pueden sacar del otro" (C. Halloway en
> La Feria de las Tinieblas, R. Bradbury)
>
Hi,
This is continuation of review.

+ elog(WARNING, "hoping nothing needed here");

the above warning can be dropped.

+ ExprState *mas_whenqual; /* WHEN [NOT] MATCHED AND conditions */

In my earlier comment I suggested changing notMatched to unmatched - I
didn't pay attention to the syntax.
That suggestion can be ignored.

Cheers

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2021-11-13 02:59:52 Re: Allow users to choose what happens when recovery target is not reached
Previous Message Zhihong Yu 2021-11-13 01:40:57 Re: support for MERGE