Re: MERGE ... RETURNING

Dean Rasheed <dean.a.rasheed@gmail.com>

From: Dean Rasheed <dean.a.rasheed@gmail.com>

To: Jeff Davis <pgsql@j-davis.com>

Cc: Isaac Morland <isaac.morland@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>

Date: 2023-07-13T17:01:44Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Add RETURNING support to MERGE.
- c649fa24a42b 17.0 landed
doc: Improve a couple of places in the MERGE docs.
- 97d4262683ac 17.0 landed
- d4c573d8e81e 16.3 landed
- a875743ff402 15.7 landed
doc: improve description of privileges for MERGE and update glossary.
- 4bc8f29088f8 17.0 landed
- 3b6728910ace 16.2 landed
- ff772853d02e 15.6 landed
Fix RLS policy usage in MERGE.
- c2e08b04c9e7 17.0 cited
Fix leak of LLVM "fatal-on-oom" section counter.
- 4f4d73466d71 17.0 cited
Implement outer-level aggregates to conform to the SQL spec, with
- e649796f128b 7.4.1 cited

On Thu, 13 Jul 2023 at 17:01, Jeff Davis <pgsql@j-davis.com> wrote:
>
> MERGE can end up combining old and new values in a way that doesn't
> happen with INSERT/UPDATE/DELETE. For instance, a "MERGE ... RETURNING
> id" would return a mix of NEW.id (for INSERT/UPDATE actions) and OLD.id
> (for DELETE actions).
>

Right, but allowing OLD/NEW.colname in the RETURNING list would remove
that complication, and it shouldn't change how a bare colname
reference behaves.

> The pg_merge_action() can differentiate the old and new values, but
> it's a bit more awkward.
>

For some use cases, I can imagine allowing OLD/NEW.colname would mean
you wouldn't need pg_merge_action() (if the column was NOT NULL), so I
think the features should work well together.

Regards,
Dean