Horton

Re: MERGE ... RETURNING

Jeff Davis <pgsql@j-davis.com>

View thread
From: Jeff Davis <pgsql@j-davis.com>
To: Dean Rasheed <dean.a.rasheed@gmail.com>, Merlin Moncure <mmoncure@gmail.com>
Cc: Gurjeet Singh <gurjeet@singh.im>, Isaac Morland <isaac.morland@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-10-30T20:08:37Z
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 Fri, 2023-10-27 at 15:46 +0100, Dean Rasheed wrote:
> 
> One fiddly part is resolving the shift/reduce conflicts in the
> grammar. Specifically, on seeing "RETURNING expr when ...", there is
> ambiguity over whether the "when" is a column alias or the start of
> the next merge action. I've resolved that by assigning a slightly
> higher precedence to an expression without an alias, so WHEN is
> assumed to not be an alias. It seems pretty ugly though (in terms of
> having to duplicate so much code), and I'd be interested to know if
> there's a neater way to do it.

Can someone else comment on whether this is a reasonable solution to
the grammar problem?

> From a usability perspective, I'm still somewhat sceptical about this
> approach. It's a much more verbose syntax, and it gets quite tedious
> having to repeat the RETURNING list for every action, and keep them
> in
> sync.

If we go with the single RETURNING-clause-at-the-end approach, how
important is it that the action can be a part of an arbitrary
expression?

Perhaps something closer to your original proposal would be a good
compromise (sorry to backtrack yet again...)? It couldn't be used in an
arbitrary expression, but that also means that it couldn't end up in
the wrong kind of expression.

Regards,
	Jeff Davis