Re: MERGE ... RETURNING

Gurjeet Singh <gurjeet@singh.im>

From: Gurjeet Singh <gurjeet@singh.im>
To: jian he <jian.universality@gmail.com>
Cc: Dean Rasheed <dean.a.rasheed@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Vik Fearing <vik@postgresfriends.org>, Isaac Morland <isaac.morland@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-07-06T17:37:21Z
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 →
  1. Add RETURNING support to MERGE.

  2. doc: Improve a couple of places in the MERGE docs.

  3. doc: improve description of privileges for MERGE and update glossary.

  4. Fix RLS policy usage in MERGE.

  5. Fix leak of LLVM "fatal-on-oom" section counter.

  6. Implement outer-level aggregates to conform to the SQL spec, with

On Thu, Jul 6, 2023 at 4:07 AM jian he <jian.universality@gmail.com> wrote:
>
> On Thu, Jul 6, 2023 at 1:13 PM Gurjeet Singh <gurjeet@singh.im> wrote:

> > I think the name of function pg_merge_when_clause() can be improved.
> > How about pg_merge_when_clause_ordinal().
>
> another idea: pg_merge_action_ordinal()

Since there can be many occurrences of the same action
(INSERT/UPDATE/DELETE) in a MERGE command associated with different
conditions, I don't think action_ordinal would make sense for this
function name.

e.g.
WHEN  MATCHED and src.col1 = val1 THEN UPDATE col2 = someval1
WHEN  MATCHED and src.col1 = val2 THEN UPDATE col2 = someval2
...

When looking at the implementation code, as well, we see that the code
in this function tracks and reports the lexical position of the WHEN
clause, irrespective of the action associated with that WHEN clause.

    foreach(l, stmt->mergeWhenClauses)
    {
...
        action->index = foreach_current_index(l) + 1;

Best regards,
Gurjeet
http://Gurje.et