From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
---|---|
To: | Viktor Holmberg <v(at)viktorh(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Allow ON CONFLICT DO UPDATE to return EXCLUDED values |
Date: | 2025-10-07 21:52:04 |
Message-ID: | CAEZATCUvXZ=Tyrc_spwE4mVSfz9aLeYtQo1+YdR4zr1UA7Wa4A@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 7 Oct 2025 at 14:56, Viktor Holmberg <v(at)viktorh(dot)net> wrote:
>
> I’ve looked through this patch. As far as I can tell, everything looks good, working and well commented.
> The only nitpick I could find is a mispelling "EXLCUDED" → "EXCLUDED" in src/test/regress/expected/returning.out:464.
Thanks for looking. I'm also glad to see that you picked up the INSERT
... ON CONFLICT DO SELECT patch, because I think these 2 features
should work well together. I'll take another look at that one, but I'm
not going to have any time this week.
> A maybe bigger question, is it nice that EXCLUDED is null when no conflict occurred? I can see the logic, but I think ergonomics wise it’d be nicer to have the proposed values in EXCLUDED, no matter what happened later. Then one can check EXCLUDED.value = NEW.value to see if one’s changes were added, for example.
Hmm, I'm not sure. I think it would be counter-intuitive to have
non-null EXCLUDED values for rows that weren't excluded, and I think
it's just as easy to check what values were added either way.
Regards,
Dean
From | Date | Subject | |
---|---|---|---|
Previous Message | Peter Smith | 2025-10-07 21:39:43 | Re: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE |