> > Would this seem a reasonable thing to do? Does anyone rely on COPY > > FROM causing an ERROR on duplicate input? > > Yes. This change will not be acceptable unless it's made an optional > (and not default, IMHO, though perhaps that's negotiable) feature of > COPY. > > The implementation might be rather messy too. I don't much > care for the > notion of a routine as low-level as bt_check_unique knowing that the > context is or is not COPY. We might have to do some restructuring. > > > Would: > > WITH ON_DUPLICATE = CONTINUE|TERMINATE (or similar) > > need to be added to the COPY command (I hope not)? > > It occurs to me that skip-the-insert might be a useful option for > INSERTs that detect a unique-key conflict, not only for COPY. (Cf. > the regular discussions we see on whether to do INSERT first or > UPDATE first when the key might already exist.) Maybe a SET variable > that applies to all forms of insertion would be appropriate.
Imho yes, but: I thought that the problem was, that you cannot simply skip the insert, because at that time the tuple (pointer) might have already been successfully inserted into an other index/heap, and thus this was only sanely possible with savepoints/undo. An idea would probably be to at once mark the new tuple dead, and proceed normally? Andreas ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
