Re: MERGE ... RETURNING
| От | Merlin Moncure |
|---|---|
| Тема | Re: MERGE ... RETURNING |
| Дата | |
| Msg-id | CAHyXU0xYJFWt9uXVkxTEDp8XYbnnDLSuA2ei25Tuavj+cwt1Uw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: MERGE ... RETURNING (Jeff Davis <pgsql@j-davis.com>) |
| Ответы |
Re: MERGE ... RETURNING
|
| Список | pgsql-hackers |
On Tue, Oct 24, 2023 at 2:11 PM Jeff Davis <pgsql@j-davis.com> wrote:
On Wed, 2023-08-23 at 11:58 +0100, Dean Rasheed wrote:
> Updated version attached, fixing an uninitialized-variable warning
> from the cfbot.
I took another look and I'm still not comfortable with the special
IsMergeSupportFunction() functions. I don't object necessarily -- if
someone else wants to commit it, they can -- but I don't plan to commit
it in this form.
Can we revisit the idea of a per-WHEN RETURNING clause? The returning
clauses could be treated kind of like a UNION, which makes sense
because it really is a union of different results (the returned tuples
from an INSERT are different than the returned tuples from a DELETE).
You can just add constants to the target lists to distinguish which
WHEN clause they came from.
I know you rejected that approach early on, but perhaps it's worth
discussing further?
Yeah. Side benefit, the 'action_number' felt really out of place, and that neatly might solve it. It doesn't match tg_op, for example. With the current approach, return a text, or an enum? Why doesn't it match concepts that are pretty well established elsewhere? SQL has a pretty good track record for not inventing weird numbers with no real meaning (sadly, not so much the developers). Having said that, pg_merge_action() doesn't feel too bad if the syntax issues can be worked out.
Very supportive of the overall goal.
merlin
В списке pgsql-hackers по дате отправления: