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
