Horton

Re: MERGE ... RETURNING

Vik Fearing <vik@postgresfriends.org>

View thread
From: Vik Fearing <vik@postgresfriends.org>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: Jeff Davis <pgsql@j-davis.com>, Gurjeet Singh <gurjeet@singh.im>, Isaac Morland <isaac.morland@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-11-01T11:17:50Z
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 11/1/23 11:12, Dean Rasheed wrote:
> On Tue, 31 Oct 2023 at 23:19, Vik Fearing <vik@postgresfriends.org> wrote:
>>
>> On 10/31/23 19:28, Jeff Davis wrote:
>>
>>> Assuming we have one RETURNING clause at the end, then it creates the
>>> problem of how to communicate which WHEN clause a tuple came from,
>>> whether it's the old or the new version, and/or which action was
>>> performed on that tuple.
>>>
>>> How do we communicate any of those things? We need to get that
>>> information into the result table somehow, so it should probably be
>>> some kind of expression that can exist in the RETURNING clause. But
>>> what kind of expression?
>>>
>>> (a) It could be a totally new expression kind with a new keyword (or
>>> recycling some existing keywords for the same effect, or something that
>>> looks superficially like a function call but isn't) that's only valid
>>> in the RETURNING clause of a MERGE statement. If you use it in another
>>> expression (say the targetlist of a SELECT statement), then you'd get a
>>> failure at parse analysis time.
>>
>> This would be my choice, the same as how the standard GROUPING()
>> "function" for grouping sets is implemented by GroupingFunc.
>>
> 
> Something I'm wondering about is to what extent this discussion is
> driven by concerns about aspects of the implementation (specifically,
> references to function OIDs in code), versus a desire for a different
> user-visible syntax. To a large extent, those are orthogonal
> questions.


For my part, I am most concerned about the language level.  I am 
sympathetic to the implementers' issues, but that is not my main focus.

So please do not take my implementation advice into account when I voice 
my opinions.
-- 
Vik Fearing