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