On Fri, 8 Mar 2024 at 08:41, <walther@technowledgy.de> wrote:
>
> I can't judge the grammar and complexity issues, but as a potential user
> it seems to me to be less complex to have multiple RETURNING clauses,
> where I could inject my own constants about the specific actions, than
> to have to deal with any of the suggested functions / clauses. More
> repetitive, yes - but not more complex.
>
> More importantly, I could add RETURNING to only some of the actions and
> not always all at the same time - which seems pretty useful to me.
>
I think that would be a bad idea, since it would mean the number of
rows returned would no longer match the number of rows modified, which
is a general property of all data-modifying commands that support
RETURNING. It would also increase the chances of bugs for users who
might accidentally miss a WHEN clause.
Looking back over the thread the majority opinion seems to be:
1). Have a single RETURNING list, rather than one per action
2). Drop the "clause number" function
3). Call the other function MERGE_ACTION()
And from an implementation point-of-view, it seems better to stick
with having a new node type to handle MERGE_ACTION(), and make
MERGE_ACTION a COL_NAME_KEYWORD.
This seems like a reasonable compromise, and it still allows the
specific WHEN clause that was executed to be identified by using a
combination of MERGE_ACTION() and the attributes from the source and
target relations. More functions can always be added later, if there
is demand.
Attached is a rebased patch, with those changes.
Regards,
Dean
