Horton

Re: MERGE ... RETURNING

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

View thread
From: Dean Rasheed <dean.a.rasheed@gmail.com>
To: walther@technowledgy.de
Cc: Jeff Davis <pgsql@j-davis.com>, Vik Fearing <vik@postgresfriends.org>, Gurjeet Singh <gurjeet@singh.im>, Isaac Morland <isaac.morland@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, jian he <jian.universality@gmail.com>
Date: 2024-03-10T15:22:49Z
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

Attachments

On Fri, 8 Mar 2024 at 08:41, <walther@technowledgy.de> wrote:
>
> I can't judge the grammar and complexity issues, but as a potential user
> it seems to me to be less complex to have multiple RETURNING clauses,
> where I could inject my own constants about the specific actions, than
> to have to deal with any of the suggested functions / clauses. More
> repetitive, yes - but not more complex.
>
> More importantly, I could add RETURNING to only some of the actions and
> not always all at the same time - which seems pretty useful to me.
>

I think that would be a bad idea, since it would mean the number of
rows returned would no longer match the number of rows modified, which
is a general property of all data-modifying commands that support
RETURNING. It would also increase the chances of bugs for users who
might accidentally miss a WHEN clause.

Looking back over the thread the majority opinion seems to be:

1). Have a single RETURNING list, rather than one per action
2). Drop the "clause number" function
3). Call the other function MERGE_ACTION()

And from an implementation point-of-view, it seems better to stick
with having a new node type to handle MERGE_ACTION(), and make
MERGE_ACTION a COL_NAME_KEYWORD.

This seems like a reasonable compromise, and it still allows the
specific WHEN clause that was executed to be identified by using a
combination of MERGE_ACTION() and the attributes from the source and
target relations. More functions can always be added later, if there
is demand.

Attached is a rebased patch, with those changes.

Regards,
Dean