Re: support for MERGE

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, Japin Li <japinli(at)hotmail(dot)com>
Cc: Zhihong Yu <zyu(at)yugabyte(dot)com>, Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Daniel Westermann <dwe(at)dbi-services(dot)com>, Erik Rijkers <er(at)xs4all(dot)nl>, Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: support for MERGE
Date: 2022-03-17 18:36:48
Message-ID: 202203171836.ewk25joolhwc@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2022-Mar-17, Alvaro Herrera wrote:

> I'll see what to do about Instrumentation->nfiltered{1,2,3} that was
> complained about by Andres upthread. Maybe some additional macros will
> help.

This turns out not to be as simple as I expected, mostly because we want
to keep Instrumentation as a node-agnostic struct. Things are already a
bit wonky with nfiltered/nfiltered2, and the addition of nfiltered3
makes things a lot uglier, and my impulse of using a union to separate
what is used for scans/joins vs. what is used for MERGE results in an
even more node-specific definition rather than the other way around.

Looking at the history I came across this older thread where this was
particularly this message from Robert,

I'll keep looking at this in the coming days, see if I can come up with
something sensible.

Álvaro Herrera 39°49'30"S 73°17'W —
Y una voz del caos me habló y me dijo
"Sonríe y sé feliz, podría ser peor".
Y sonreí. Y fui feliz.
Y fue peor.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2022-03-17 19:11:32 Re: Column Filtering in Logical Replication
Previous Message Joshua Brindle 2022-03-17 18:19:48 Re: Granting SET and ALTER SYSTE privileges for GUCs