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

From Jeff Davis
Subject Re: MERGE ... RETURNING
Date
Msg-id 0278f03e955ef21d2e3fe615f63db299346bfa7a.camel@j-davis.com
Whole thread Raw
In response to Re: MERGE ... RETURNING  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Responses Re: MERGE ... RETURNING
Re: MERGE ... RETURNING
List pgsql-hackers
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?

Regards,
    Jeff Davis




pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Bug: RLS policy FOR SELECT is used to check new rows
Next
From: Alexander Korotkov
Date:
Subject: Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.