From: | Vik Fearing <vik(at)postgresfriends(dot)org> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, Gurjeet Singh <gurjeet(at)singh(dot)im>, Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: MERGE ... RETURNING |
Date: | 2023-11-01 11:17:50 |
Message-ID: | 93984020-ffb9-4e4c-b419-9d1d3fc03b19@postgresfriends.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11/1/23 11:12, Dean Rasheed wrote:
> On Tue, 31 Oct 2023 at 23:19, Vik Fearing <vik(at)postgresfriends(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Aleksander Alekseev | 2023-11-01 11:44:07 | Re: Don't pass NULL pointer to strcmp(). |
Previous Message | Aleksander Alekseev | 2023-11-01 11:12:30 | Re: pg_resetwal tests, logging, and docs update |