Insérer, lors d'une mise à jour en double dans PostgreSQL?

Il y a plusieurs mois, j'ai appris d'une réponse sur Stack Overflow comment effectuer plusieurs mises à jour à la fois dans MySQL en utilisant la syntaxe suivante:

INSERT INTO table (id, field, field2) VALUES (1, A, X), (2, B, Y), (3, C, Z)
ON DUPLICATE KEY UPDATE field=VALUES(Col1), field2=VALUES(Col2);

Je suis maintenant passé à PostgreSQL et apparemment, ce n'est pas correct. Cela fait référence à toutes les tables correctes, donc je suppose que c'est une question de mots-clés différents utilisés, mais je ne sais pas où dans la documentation PostgreSQL cela est couvert.

Pour clarifier, je veux insérer plusieurs choses et si elles existent déjà pour les mettre à jour.

PostgreSQL depuis la version 9.5 a la syntaxe UPSERT , avec la clause ON CONFLICT . avec la syntaxe suivante (similaire à MySQL)

INSERT INTO the_table (id, column_1, column_2) 
VALUES (1, 'A', 'X'), (2, 'B', 'Y'), (3, 'C', 'Z')
ON CONFLICT (id) DO UPDATE 
  SET column_1 = excluded.column_1, 
      column_2 = excluded.column_2;

La recherche dans les archives du groupe de messagerie de postgresql de "upsert" conduit à trouver un exemple de ce que vous voulez faire, dans le manuel :

Exemple 38-2. Exceptions avec UPDATE / INSERT

Cet exemple utilise la gestion des exceptions pour effectuer UPDATE ou INSERT, selon le cas:

CREATE TABLE db (a INT PRIMARY KEY, b TEXT);

CREATE FUNCTION merge_db(key INT, data TEXT) RETURNS VOID AS
$$
BEGIN
    LOOP
        -- first try to update the key
        -- note that "a" must be unique
        UPDATE db SET b = data WHERE a = key;
        IF found THEN
            RETURN;
        END IF;
        -- not there, so try to insert the key
        -- if someone else inserts the same key concurrently,
        -- we could get a unique-key failure
        BEGIN
            INSERT INTO db(a,b) VALUES (key, data);
            RETURN;
        EXCEPTION WHEN unique_violation THEN
            -- do nothing, and loop to try the UPDATE again
        END;
    END LOOP;
END;
$$
LANGUAGE plpgsql;

SELECT merge_db(1, 'david');
SELECT merge_db(1, 'dennis');

Il y a peut-être un exemple de la façon de le faire en masse, en utilisant les CTE dans 9.1 et au-dessus, dans la liste de diffusion des pirates :

WITH foos AS (SELECT (UNNEST(%foo[])).*)
updated as (UPDATE foo SET foo.a = foos.a ... RETURNING foo.id)
INSERT INTO foo SELECT foos.* FROM foos LEFT JOIN updated USING(id)
WHERE updated.id IS NULL;

Voir la réponse de a_horse_with_no_name pour un exemple plus clair.

Avertissement: ce n'est pas sûr s'il est exécuté à partir de plusieurs sessions en même temps (voir les mises en garde ci-dessous).

Une autre façon intelligente de faire un "UPSERT" dans postgresql est de faire deux instructions UPDATE / INSERT séquentielles conçues chacune pour réussir ou pour n'avoir aucun effet.

UPDATE table SET field='C', field2='Z' WHERE id=3;
INSERT INTO table (id, field, field2)
       SELECT 3, 'C', 'Z'
       WHERE NOT EXISTS (SELECT 1 FROM table WHERE id=3);

La MISE À JOUR réussira si une ligne avec "id = 3" existe déjà, sinon elle n'a aucun effet.

L'INSERT ne réussira que si la ligne avec "id = 3" n'existe pas déjà.

Vous pouvez combiner ces deux éléments en une seule chaîne et les exécuter tous les deux avec une seule instruction SQL exécutée à partir de votre application. Les exécuter ensemble en une seule transaction est fortement recommandé.

Cela fonctionne très bien lorsqu'il est exécuté de manière isolée ou sur une table verrouillée, mais est soumis à des conditions de concurrence qui signifie qu'il peut toujours échouer avec une erreur de clé en double si une ligne est insérée simultanément, ou peut se terminer sans aucune ligne insérée lorsqu'une ligne est supprimée simultanément . Une SERIALIZABLEtransaction sur PostgreSQL 9.1 ou supérieur la traitera de manière fiable au prix d'un taux d'échec de sérialisation très élevé, ce qui signifie que vous devrez réessayer beaucoup. Voyez pourquoi est upsert si compliqué , qui traite de ce cas plus en détail.

Cette approche est également sujette à des mises à jour perdues read committedisolément, à moins que l'application ne vérifie le nombre de lignes affectées et ne vérifie que la insertou la ligne updateaffectée .

Avec PostgreSQL 9.1 cela peut être réalisé en utilisant un CTE inscriptible ( expression de table commune ):

WITH new_values (id, field1, field2) as (
  values 
     (1, 'A', 'X'),
     (2, 'B', 'Y'),
     (3, 'C', 'Z')

),
upsert as
( 
    update mytable m 
        set field1 = nv.field1,
            field2 = nv.field2
    FROM new_values nv
    WHERE m.id = nv.id
    RETURNING m.*
)
INSERT INTO mytable (id, field1, field2)
SELECT id, field1, field2
FROM new_values
WHERE NOT EXISTS (SELECT 1 
                  FROM upsert up 
                  WHERE up.id = new_values.id)

Voir ces entrées de blog:

• Renversement via CTE inscriptible
• EN ATTENTE DE 9.1 - CTE ÉCRITABLE
• POURQUOI UPSERT EST-IL SI COMPLIQUÉ?

Notez que cette solution n'empêche pas une violation de clé unique mais qu'elle n'est pas vulnérable aux mises à jour perdues.
Voir le suivi de Craig Ringer sur dba.stackexchange.com

Dans PostgreSQL 9.5 et plus récent, vous pouvez utiliser INSERT ... ON CONFLICT UPDATE.

Consultez la documentation .

Un MySQL INSERT ... ON DUPLICATE KEY UPDATEpeut être directement reformulé en a ON CONFLICT UPDATE. La syntaxe standard SQL n'est pas non plus, ce sont deux extensions spécifiques à la base de données. Il y a de bonnes raisons pour lesquelles cela MERGEn'a pas été utilisé , une nouvelle syntaxe n'a pas été créée juste pour le plaisir. (La syntaxe de MySQL a également des problèmes qui signifient qu'elle n'a pas été adoptée directement).

par exemple, configuration donnée:

CREATE TABLE tablename (a integer primary key, b integer, c integer);
INSERT INTO tablename (a, b, c) values (1, 2, 3);

la requête MySQL:

INSERT INTO tablename (a,b,c) VALUES (1,2,3)
  ON DUPLICATE KEY UPDATE c=c+1;

devient:

INSERT INTO tablename (a, b, c) values (1, 2, 10)
ON CONFLICT (a) DO UPDATE SET c = tablename.c + 1;

Différences:

• Vous devez spécifier le nom de colonne (ou le nom de contrainte unique) à utiliser pour la vérification d'unicité. C'est leON CONFLICT (columnname) DO

• Le mot-clé SETdoit être utilisé, comme s'il s'agissait d'une UPDATEinstruction normale

Il a aussi de belles fonctionnalités:

• Vous pouvez avoir une WHEREclause sur votre UPDATE(vous permettant de transformer efficacement ON CONFLICT UPDATEen ON CONFLICT IGNOREcertaines valeurs)

• Les valeurs proposées pour l'insertion sont disponibles en tant que variable de ligne EXCLUDED, qui a la même structure que la table cible. Vous pouvez obtenir les valeurs d'origine dans la table en utilisant le nom de la table. Donc, dans ce cas, ce EXCLUDED.csera 10(parce que c'est ce que nous avons essayé d'insérer) et ce "table".csera 3parce que c'est la valeur actuelle dans le tableau. Vous pouvez utiliser l'un ou les deux dans les SETexpressions et la WHEREclause.

Pour des informations sur upsert, voir Comment UPSERT (MERGE, INSERT ... ON DUPLICATE UPDATE) dans PostgreSQL?

Je cherchais la même chose quand je suis venu ici, mais le manque d'une fonction générique "upsert" m'a un peu dérangé alors j'ai pensé que vous pouviez simplement passer la mise à jour et insérer sql comme arguments sur cette fonction du manuel

cela ressemblerait à ceci:

CREATE FUNCTION upsert (sql_update TEXT, sql_insert TEXT)
    RETURNS VOID
    LANGUAGE plpgsql
AS $$
BEGIN
    LOOP
        -- first try to update
        EXECUTE sql_update;
        -- check if the row is found
        IF FOUND THEN
            RETURN;
        END IF;
        -- not found so insert the row
        BEGIN
            EXECUTE sql_insert;
            RETURN;
            EXCEPTION WHEN unique_violation THEN
                -- do nothing and loop
        END;
    END LOOP;
END;
$$;

et peut-être pour faire ce que vous vouliez initialement faire, batch "upsert", vous pouvez utiliser Tcl pour diviser sql_update et boucler les mises à jour individuelles, le hit de pré-performance sera très petit voir http://archives.postgresql.org/pgsql- performance / 2006-04 / msg00557.php

le coût le plus élevé est l'exécution de la requête à partir de votre code, du côté de la base de données, le coût d'exécution est beaucoup plus faible

Il n'y a pas de commande simple pour le faire.

L'approche la plus correcte consiste à utiliser la fonction, comme celle des documents .

Une autre solution (bien que moins sûre) consiste à effectuer une mise à jour avec retour, à vérifier quelles lignes étaient des mises à jour et à insérer les autres

Quelque chose dans le sens de:

update table
set column = x.column
from (values (1,'aa'),(2,'bb'),(3,'cc')) as x (id, column)
where table.id = x.id
returning id;

en supposant que id: 2 a été renvoyé:

insert into table (id, column) values (1, 'aa'), (3, 'cc');

Bien sûr, il renflouera tôt ou tard (dans un environnement simultané), car il y a une condition de course claire ici, mais généralement cela fonctionnera.

Voici un article plus long et plus complet sur le sujet .

Personnellement, j'ai mis en place une "règle" attachée à l'instruction d'insertion. Supposons que vous disposiez d'une table "DNS" qui enregistre les hits DNS par client sur une base de temps:

CREATE TABLE dns (
    "time" timestamp without time zone NOT NULL,
    customer_id integer NOT NULL,
    hits integer
);

Vous vouliez pouvoir réinsérer des lignes avec des valeurs mises à jour ou les créer si elles n'existaient pas déjà. Saisissez l'identifiant client et l'heure. Quelque chose comme ça:

CREATE RULE replace_dns AS 
    ON INSERT TO dns 
    WHERE (EXISTS (SELECT 1 FROM dns WHERE ((dns."time" = new."time") 
            AND (dns.customer_id = new.customer_id)))) 
    DO INSTEAD UPDATE dns 
        SET hits = new.hits 
        WHERE ((dns."time" = new."time") AND (dns.customer_id = new.customer_id));

Mise à jour: cela peut échouer si des insertions simultanées se produisent, car cela générera des exceptions de violation unique. Cependant, la transaction non terminée se poursuivra et réussira, et il vous suffit de répéter la transaction terminée.

Cependant, s'il y a des tonnes d'insertions tout le temps, vous souhaiterez mettre un verrou de table autour des instructions d'insertion: le verrouillage SHARE ROW EXCLUSIVE empêchera toutes les opérations qui pourraient insérer, supprimer ou mettre à jour des lignes dans votre table cible. Cependant, les mises à jour qui ne mettent pas à jour la clé unique sont sûres. Par conséquent, si aucune opération ne le fait, utilisez plutôt des verrous consultatifs.

De plus, la commande COPY n'utilise pas de RULES, donc si vous insérez avec COPY, vous devrez utiliser des déclencheurs à la place.

J'utilise cette fonction de fusion

CREATE OR REPLACE FUNCTION merge_tabla(key INT, data TEXT)
  RETURNS void AS
$BODY$
BEGIN
    IF EXISTS(SELECT a FROM tabla WHERE a = key)
        THEN
            UPDATE tabla SET b = data WHERE a = key;
        RETURN;
    ELSE
        INSERT INTO tabla(a,b) VALUES (key, data);
        RETURN;
    END IF;
END;
$BODY$
LANGUAGE plpgsql

J'ai personnalisé la fonction "upsert" ci-dessus, si vous voulez INSÉRER ET REMPLACER:

"

 CREATE OR REPLACE FUNCTION upsert(sql_insert text, sql_update text)

 RETURNS void AS
 $BODY$
 BEGIN
    -- first try to insert and after to update. Note : insert has pk and update not...

    EXECUTE sql_insert;
    RETURN;
    EXCEPTION WHEN unique_violation THEN
    EXECUTE sql_update; 
    IF FOUND THEN 
        RETURN; 
    END IF;
 END;
 $BODY$
 LANGUAGE plpgsql VOLATILE
 COST 100;
 ALTER FUNCTION upsert(text, text)
 OWNER TO postgres;`

Et après l'exécution, faites quelque chose comme ceci:

SELECT upsert($$INSERT INTO ...$$,$$UPDATE... $$)

Est important de mettre une double virgule pour éviter les erreurs du compilateur

• vérifier la vitesse ...

Semblable à la réponse la plus appréciée, mais fonctionne légèrement plus rapidement:

WITH upsert AS (UPDATE spider_count SET tally=1 WHERE date='today' RETURNING *)
INSERT INTO spider_count (spider, tally) SELECT 'Googlebot', 1 WHERE NOT EXISTS (SELECT * FROM upsert)

(source: http://www.the-art-of-web.com/sql/upsert/ )

J'ai le même problème de gestion des paramètres de compte que les paires de valeurs de nom. Le critère de conception est que différents clients peuvent avoir des ensembles de paramètres différents.

Ma solution, similaire à JWP, consiste à effacer et remplacer en bloc, générant l'enregistrement de fusion dans votre application.

C'est assez à l'épreuve des balles, indépendant de la plate-forme et comme il n'y a jamais plus de 20 paramètres par client, ce ne sont que 3 appels db à charge assez faible - probablement la méthode la plus rapide.

L'alternative de mettre à jour des lignes individuelles - vérifier les exceptions puis insérer - ou une combinaison de codes hideux, lents et se casse souvent parce que (comme mentionné ci-dessus) la gestion des exceptions SQL non standard passant de db à db - ou même de version en version.

 #This is pseudo-code - within the application:
 BEGIN TRANSACTION - get transaction lock
 SELECT all current name value pairs where id = $id into a hash record
 create a merge record from the current and update record
  (set intersection where shared keys in new win, and empty values in new are deleted).
 DELETE all name value pairs where id = $id
 COPY/INSERT merged records 
 END TRANSACTION

Selon la documentation PostgreSQL de l' INSERTinstruction , la gestion du ON DUPLICATE KEYcas n'est pas prise en charge. Cette partie de la syntaxe est une extension MySQL propriétaire.

CREATE OR REPLACE FUNCTION save_user(_id integer, _name character varying)
  RETURNS boolean AS
$BODY$
BEGIN
    UPDATE users SET name = _name WHERE id = _id;
    IF FOUND THEN
        RETURN true;
    END IF;
    BEGIN
        INSERT INTO users (id, name) VALUES (_id, _name);
    EXCEPTION WHEN OTHERS THEN
            UPDATE users SET name = _name WHERE id = _id;
        END;
    RETURN TRUE;
END;

$BODY$
  LANGUAGE plpgsql VOLATILE STRICT

Pour fusionner de petits ensembles, l'utilisation de la fonction ci-dessus est très bien. Cependant, si vous fusionnez de grandes quantités de données, je vous suggère de consulter http://mbk.projects.postgresql.org

La meilleure pratique actuelle que je connaisse est:

1. COPIEZ les données nouvelles / mises à jour dans la table temporaire (bien sûr, ou vous pouvez l'insérer si le coût est correct)
2. Acquérir le verrou [facultatif] (le conseil est préférable aux verrous de table, IMO)
3. Fusionner. (la partie amusante)

UPDATE renverra le nombre de lignes modifiées. Si vous utilisez JDBC (Java), vous pouvez alors comparer cette valeur à 0 et, si aucune ligne n'a été affectée, déclencher INSERT à la place. Si vous utilisez un autre langage de programmation, peut-être que le nombre de lignes modifiées peut encore être obtenu, consultez la documentation.

Cela peut ne pas être aussi élégant, mais vous disposez d'un SQL beaucoup plus simple et plus simple à utiliser à partir du code appelant. Différemment, si vous écrivez le script de dix lignes en PL / PSQL, vous devriez probablement avoir un test unitaire de l'un ou l'autre type juste pour lui seul.

Modifier: cela ne fonctionne pas comme prévu. Contrairement à la réponse acceptée, cela produit des violations de clé uniques lorsque deux processus appellent à plusieurs reprises upsert_foosimultanément.

Eureka! J'ai trouvé un moyen de le faire dans une seule requête: utilisez UPDATE ... RETURNINGpour tester si des lignes ont été affectées:

CREATE TABLE foo (k INT PRIMARY KEY, v TEXT);

CREATE FUNCTION update_foo(k INT, v TEXT)
RETURNS SETOF INT AS $$
    UPDATE foo SET v = $2 WHERE k = $1 RETURNING $1
$$ LANGUAGE sql;

CREATE FUNCTION upsert_foo(k INT, v TEXT)
RETURNS VOID AS $$
    INSERT INTO foo
        SELECT $1, $2
        WHERE NOT EXISTS (SELECT update_foo($1, $2))
$$ LANGUAGE sql;

Le UPDATEdoit être fait dans une procédure distincte parce que, malheureusement, cela est une erreur de syntaxe:

... WHERE NOT EXISTS (UPDATE ...)

Maintenant, cela fonctionne comme vous le souhaitez:

SELECT upsert_foo(1, 'hi');
SELECT upsert_foo(1, 'bye');
SELECT upsert_foo(3, 'hi');
SELECT upsert_foo(3, 'bye');