I've pushed a simplified (no refactoring) version of the fix proposed by Thomas and Peter, so that we have some kind of fix in place for tomorrow's releases. I think further improvement along the lines suggested by Kevin can wait till later. I noticed that the ON CONFLICT DO NOTHING and ON CONFLICT DO UPDATE cases are now not terribly consistent about what to do with self-conflicting insertions. The examples memorialized in commit a6c0a5b6e are insert into selfconflict values (1,1), (1,2) on conflict do nothing; -- succeeds, inserting the first row and ignoring the second insert into selfconflict values (4,1), (4,2) on conflict(f1) do update set f2 = 0; ERROR: ON CONFLICT DO UPDATE command cannot affect row a second time HINT: Ensure that no rows proposed for insertion within the same command have duplicate constrained values. I think that if we believe the first behavior is correct, then the second behavior is a bug; what that command should do is to insert a single row containing (4,0). However, that behavior is the same across all isolation levels, and it was like that before today's patches, so I didn't undertake to do anything about it right now. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
