Re: MERGE ... RETURNING - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: MERGE ... RETURNING
Date
Msg-id CAHyXU0xYJFWt9uXVkxTEDp8XYbnnDLSuA2ei25Tuavj+cwt1Uw@mail.gmail.com
Whole thread Raw
In response to Re: MERGE ... RETURNING  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: MERGE ... RETURNING
List pgsql-hackers
On Tue, Oct 24, 2023 at 2:11 PM Jeff Davis <pgsql@j-davis.com> wrote:
On Wed, 2023-08-23 at 11:58 +0100, Dean Rasheed wrote:
> Updated version attached, fixing an uninitialized-variable warning
> from the cfbot.

I took another look and I'm still not comfortable with the special
IsMergeSupportFunction() functions. I don't object necessarily -- if
someone else wants to commit it, they can -- but I don't plan to commit
it in this form.

Can we revisit the idea of a per-WHEN RETURNING clause? The returning
clauses could be treated kind of like a UNION, which makes sense
because it really is a union of different results (the returned tuples
from an INSERT are different than the returned tuples from a DELETE).
You can just add constants to the target lists to distinguish which
WHEN clause they came from.

I know you rejected that approach early on, but perhaps it's worth
discussing further?

 Yeah.  Side benefit, the 'action_number' felt really out of place, and that neatly might solve it.  It doesn't match tg_op, for example.  With the current approach, return a text, or an enum? Why doesn't it match concepts that are pretty well established elsewhere?  SQL has a pretty good track record for not inventing weird numbers with no real meaning (sadly, not so much the developers).   Having said that, pg_merge_action() doesn't feel too bad if the syntax issues can be worked out.

Very supportive of the overall goal.

merlin

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Making aggregate deserialization (and WAL receive) functions slightly faster
Next
From: Nathan Bossart
Date:
Subject: Re: CRC32C Parallel Computation Optimization on ARM