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>
Cc: Isaac Morland <isaac.morland@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-07-17T19:43:10Z
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-07-14 at 09:55 +0100, Dean Rasheed wrote:
> I found a 10-year-old thread discussing adding support for OLD/NEW to
> RETURNING [1], but it doesn't look like anything close to a
> committable solution was developed, or even a design that might lead
> to one. That's a shame, because there seemed to be a lot of demand
> for
> the feature, but it's not clear how much effort it would be to
> implement.

It looks like progress was made in the direction of using a table alias
with executor support to bring the right attributes along.

There was some concern about how exactly the table alias should work
such that it doesn't look too much like a join. Not sure how much of a
problem that is.

> > Maybe instead of a function it could be a special table reference
> > like:
> > 
> >   MERGE ... RETURNING MERGE.action, MERGE.action_number, id, val?
> > 
> 
> Well, that's a little more concise, but I'm not sure that it really
> buys us that much, to be worth the extra complication. Presumably
> something in the planner would turn that into something the executor
> could handle, which might just end up being the existing functions
> anyway.

The benefits are:

1. It is naturally constrained to the right context. It doesn't require
global variables and the PG_TRY/PG_FINALLY, and can't be called in the
wrong contexts (like SELECT).

2. More likely to be consistent with eventual support for NEW/OLD
(actually BEFORE/AFTER for reasons the prior thread discussed).

I'm not sure how much extra complication it would cause, though.

Regards,
	Jeff Davis