Je voudrais proposer une autre réflexion pour répondre spécifiquement à votre phrase: "Je veux donc vérifier si une seule ligne du lot existe dans le tableau parce qu'alors je sais qu'elles ont toutes été insérées ."
Vous rendez les choses efficaces en insérant des "lots" mais en effectuant ensuite des vérifications d'existence un enregistrement à la fois? Cela me semble contre-intuitif. Donc, quand vous dites "les insertions sont toujours effectuées par lots ", je suppose que vous voulez dire que vous insérez plusieurs enregistrements avec une instruction d'insertion . Vous devez vous rendre compte que Postgres est conforme à ACID. Si vous insérez plusieurs enregistrements (un lot de données) avec une instruction d'insertion , il n'est pas nécessaire de vérifier si certains ont été insérés ou non. L'instruction réussit ou échouera. Tous les enregistrements seront insérés ou aucun.
D'un autre côté, si votre code C # fait simplement un "set" d'instructions d'insertion séparées, par exemple, dans une boucle, et dans votre esprit, c'est un "batch" .. alors vous ne devriez pas en fait le décrire comme " les insertions se font toujours par lots ". Le fait que vous vous attendiez à ce qu'une partie de ce que vous appelez un "lot" ne soit en fait pas insérée, et par conséquent ressentiez le besoin d'une vérification, suggère fortement que c'est le cas, auquel cas vous avez un problème plus fondamental. Vous devez modifier votre paradigme pour insérer réellement plusieurs enregistrements avec une seule insertion et renoncer à vérifier si les enregistrements individuels l'ont fait.
Prenons cet exemple:
CREATE TABLE temp_test (
id SERIAL PRIMARY KEY,
sometext TEXT,
userid INT,
somethingtomakeitfail INT unique
)
-- insert a batch of 3 rows
;;
INSERT INTO temp_test (sometext, userid, somethingtomakeitfail) VALUES
('foo', 1, 1),
('bar', 2, 2),
('baz', 3, 3)
;;
-- inspect the data of what we inserted
SELECT * FROM temp_test
;;
-- this entire statement will fail .. no need to check which one made it
INSERT INTO temp_test (sometext, userid, somethingtomakeitfail) VALUES
('foo', 2, 4),
('bar', 2, 5),
('baz', 3, 3) -- <<--(deliberately simulate a failure)
;;
-- check it ... everything is the same from the last successful insert ..
-- no need to check which records from the 2nd insert may have made it in
SELECT * FROM temp_test
C'est en fait le paradigme de toute base de données compatible ACID ... pas seulement de Postgresql. En d'autres termes, vous êtes mieux si vous corrigez votre concept de «lot» et évitez d'avoir à faire des vérifications ligne par ligne en premier lieu.