Hi,
> And yet my review did figure out that your patch would have visibility
> problems, which you did end up having, as you noticed yourself downthread :)
Yep, this particular implementation turned out to be buggy.
>> I don't buy your argument about DO UPDATE needing to be brought into
>> line with DO NOTHING. In any case I'm pretty sure that Tom's remarks
>> in 2016 about a behavioral inconsistencies (which you cited) actually
>> called for making DO NOTHING more like DO UPDATE -- not the other way
>> around.
>
> Interesting. Yep, we could use a bit of input from Tom on this one.
>
> This of course would break backward compatibility. But we can always
> invent something like:
>
> ```
> INSERT INTO ..
> ON CONFLICT DO [NOTHING|UPDATE .. ]
> [ALLOWING|FORBIDDING] SELF CONFLICTS;
> ```
>
> ... if we really want to.
I suggest we discuss if we even want to support something like this
before processing further and then think about a particular
implementation if necessary.
One thing that occured to me during the discussion is that we don't
necessarily have to physically write one tuple at a time to the heap.
Alternatively we could use information about the existing unique
constraints and write only the needed tuples.
> However, extension developers, as an example, often don't know the
> underlying unique constraints (more specifically, it's difficult to
> look for them and process them manually) and often have to process any
> garbage the application developer passes to an extension.
>
> This of course is applicable not only to extensions, but to any
> middleware between the DBMS and the application.
This however is arguably a niche use case. So maybe we don't want to
spend time on this.
--
Best regards,
Aleksander Alekseev
